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Welcome to the NAPRA Notebook 


The book that you hold in your hand is the very first 
NAPRA Notebook. This is by far the biggest publica- 
tion that I've ever been involved in. I'm rather proud 
of it and I hope you, as a fellow club member, will be 
as well. Hats off to all those who wrote articles, proof 
read, and generally put up with me during it's creation! 


This publication is shipped to NAPRA members an- 
nually. All articles from the NAPRA Dedicated Link 
which still apply to packet radio today are published in 
the Notebook. The Notebook also includes documentation 
needed to construct and operate the NAPRA recom- 
mended network node equipment, as well as informa- 
tion on using servers connected to the network. 


Since we're sharing articles with the North East Digital 
Association (NEDA), I've taken the liberty to include in- 
formation from their old Quarterlies in here as well as 
placing the articles we borrowed from their magazine 
for our most recent magazines in the section marked 
NEDA compendium. 

The purpose: 

The purpose of the Notebook includes being a com- 
pendium of club progress, a directory to club activities, 
a guide to network implementation and an instruction 
manual for packet network operation. In order to pro- 
mote packet networking NAPRA hopes to put all of the 
available documentation needed to build a successful 
network into the hands of any who might make good 
use of it towards the cause. 


If you have any comments about this document or any 
input that should go into the Notebook or Dedicated Link 
please contact me at: 


NAPRA 

Box 70405 

Bellevue WA 98007 

—Your Editor, Tadd Torborg - KA2DEW 
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Reading the Notebook 


If you've never seen this book be- 
fore you'll want to page through it 
and see what's there. If you are to- 
tally new to packet radio you'll have 
to skip about a bit to find the good 
stuff. Since this edition of the 
Notebook is being first read by 
members of NAPRA and second by 
people who are already packeteers 
and are looking at joining NAPRA 
this book is organized with the in- 
formation that experienced pack- 
eteers will want to see earlier in the 
book. The sections: What is Packet? 
Operating a Packet Station; How to 
use the Network, basic; Beginners 
Guide to Understanding Servers are 
probably the first ones to read. Also 
there is a glossary. See the table of 
contents. 


On the other hand, if you are an 
experienced TheNET node builder 
you are going to want to go directly 
to the goods and browse through the 
TheNET Resource Manual. I highly 
recommend that you also look at the 
sections on Hidden Transmitter 
Syndrome and the technical articles 
in the back half of the book. If you 


haven't seen the document titled 
NAPRA Networking Recommenda- 
tions you might want to contact the 
club or one of the officers. 


Since this is a rather large publi- 
cation it may be rather hard to read 
from cover to cover. This is especially 
true when this is the second edition 
of the book that you've received. I've 
found one of the least painful ways 
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to go through it a second or third time 
is to use the book to explain packet 
networking to a newcomer. (see how 
we get you to do the club's work? hi). 
Another way is to critique it. Pick 
on anything you can pick on. Look 
for things that are not said that you 
think should be. Send your com- 
ments to Notebook Editor at the club 
mailbox. 
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Northwest Amateur Packet Radio Association 


The Northwest Amateur Packet 
Radio Association was formed in 
1983 to support technical develop- 
ment of packet radio as well as to 
education of hams in the field of 
digital communications and promo- 
tion of packet radio. In the spring 
of 1992 the club reviewed it's place 
in the packet radio community and 
focussed it's purpose on providing 
technical literature and periodicals 
to support other, more local packet 
clubs in the north west. NAPRA also 
supports a packet network in the 
northwest region of the United States 
and in provinces of Canada adjoin- 
ing. The club supports the network 
with technical assistance, docu- 
mentation, promotion and by fund- 
ing custom hardware development 
when necessary (like HexiPus™ 
boards). 
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NAPRA is a member supported 
organization. Members are those 
hams who use packet radio and like 
to keep in touch with current devel- 
opments, as well as those hams who 
want to build services for their 
communities and for their region. 


Because NAPRA covers a huge 
area general meetings of all NAPRA 
members are not easy. The club, 
instead, holds local general meet- 
ings on a monthly basis and quar- 
terly board of directors meetings in 
a central location. If there is no 
general meeting in your area you can 
work with the club to start one. 
NAPRA also recognizes independant 
packet radio clubs. Please read the 
General Meetings part of the Bylaws 
elsewhere in this Notebook. 


Getting Involved 

To get involved with NAPRA you 
can approach any of the members or 
officers via packet or at one of the 
general meetings. A complete 
membership roster is printed in the 
Dedicated Link. You can write to the 
NAPRA club address, or you can send 
mail to the editor. There is a list of 
NAPRA Elmers in the Dedicated 
Link. The Elmers are volunteers who 
are committed to promoting packet 
and packet networking and will work 
with hams of any level of interest. 
They can help with packet radio use, 
or network building. There are no 
VHF terrestrial links from the At- 
lantic to the Pacific. Why is this? 
Lets do it! 
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Packet networking can be great 
fun. It is truly amazing how much 
fun can be had by so many packeteers 
at the same time across a packet 
network. Users have access to mul- 
tiple BBSs, DxClusters, round table 
conference servers, callbook database 
servers and to other users. Hundreds 
of packeteers may be using the net- 
work at the same time. Even as a 
user is connected six or seven node 
sites away, perhaps hundreds of 
miles, to connect to a round table 
conference there may be a DxCluster 
link, TCP/IPers and BBS forwarding 
across the same path. At the same 
time several users may be probing 
through the network across the same 
paths, looking to meet other pack- 
eteers or to find new services to play 
with. 

What does this cost? How can we 
make such a system? How do we 
raise the money for our part of this 
system? Who will run it? How do 
we eliminate the politics? Is this 
really even possible? Now? 


Yes this is possible. No it doesn't 
require high tech equipment. A 
network can be built (has been built) 
which allows multiple applications 
to use it and still has enough extra 
performance for the keyboard users 
to play and have fun. Indeed it's 
imperative that the users have fun. 
The users are the ones that will be 
adding to the network! 


There are two keys to making this 
happen. #1. Build the network right 
and don't compromise; #2. Make sure 
all involved have fun. 


In this Notebook you'll find all of 
the information necessary to build 
and use a network that will perform 
as advertised. Network links can be 
built with off the shelf gear by any- 
body who can make a VHF FM radio 
work. 

Here is a brief on the kind of 
concepts that NAPRA believes will 
help us build this network: 


The network is mostly TheNET based. 
Users may connect into the network via 
2 meter access points using normal TNCs 


Network! 


and access other users and servers any- 
where in the network. 


Use of and growth of the network is 
encouraged. Users may connect to net- 
work nodes and observe how the system 
ts configured. Membership is encouraged 
but is not necessary. Members have the 
advantage of being listed in and in re- 
ceiving the Dedicated Link. Non mem- 
bers have access to this material only 
through privately photocopied copies. 
Generally members have more fun. This 
plus the fact of support of this process has 
been shown to be worth the membership 
dues. 


The network is entirely privately 
owned. NAPRA does not own any hard- 
ware in the network. NAPRA agrees to 
document the general purpose packet 
network. NAPRA recommends certain 
principals which are instrumental in 
seeing the system grow. The following 
is a brief of those principals. 


¢ The network is open for use by all 
packeteers; 


¢ The network carries traffic for key- 
board users, DxClusters, DxCluster 
users, packet mailboxes and mailbox 
users, playing of games, TCP/IP 
hosts, transferring of data or pro- 
grams and many other kinds of op- 
erations; 


¢ No user or server is more important 
than any other and must share the 
network equally (except for in emer- 
gency situations or in officially spon- 
sored emergency drills); 
¢ Network operators agree to a stan- 
dard set of parameters, within the 
limitations of the software used, such 
that equal access to all is assured; 
¢ Emergency operation and public 
service are of major importance, both 
because of the purpose of amateur 
radio and because by public service 
we get publicity and thus growth. 
As you read through this book, 
don't look at this as if it is cast in 
stone. This book is written and 
published by a club that wants to see 
you play with packet radio and have 
fun. If you wish to, or already have, 
built networking hardware you have 
our deepest appreciation. There is 
enough spectrum in most parts of the 
northwest for many different phi- 
losophies of network building. Go 
and have fun. If you build and pro- 
mote networking as this book speci- 
fies, we think you'll have more fun. 
If you don't, then what you are build- 
ing will still be there. Go out and play 
radio. It's what we amateurs do best! 


—NAPRA 


The HexiPus™ is a product of the North East Digital Association. 
This board is used to connect up to six TNCs together to construct 
a TheNET node. See table of contents for the order form. 


N.A.P.R.A.. Notebook v1.0 
© NAPRA 1992 


Page 3 


Packet is a method of communi- 
cating digitally. The word packet 
describes the manner that blocks of 
information are transmitted and 
received. Text information, either 
hand typed or computer generated, 
is transmitted from station to station 
in blocks of between 1 and 256 bytes. 
Each block is acknowledged by the 
destination station. Lost blocks are 
re-sent. This means that every block 
that a user would see on the receive 
end is guaranteed to be error free. 
This does not guarantee that all 
blocks will make it. It is up to the 
sending station to resent lost blocks. 
How and when the sending station 
transmits we'll get into later. 


Why do we packet? 


Of all of the modes of communi- 
cations used in ham radio, packet is 
the only mode which inherently al- 
lows several conversations to occur 
in the same piece of spectrum over 
the same path. This means that on 
one frequency in the 2m band sev- 
eral pairs of stations can carry on 
conversations at the same time. A 
packeteer can start a conversation on 
a frequency that may already be in 
use, without fear of hindering the 
other conversation or conversations. 
We can take advantage of a linked 
network of packet stations without 
worrying about keeping other sta- 
tions from doing the same. We can 
connect our station or computer to 
other stations to run operations that 
might last for hours or even years! 


One practical application of long 
duration packet operation is Dx 
spotting. All over the US and 
Canada DxCluster servers are con- 
nected together to share Dx spotting 
information. The way you use this is 
to packet with a local contact point 
(there are many) all the time while 
you are operating your HF station. 
Whenever you work a rare one on HF 
you can type a note to all of the other 
hams who are currently on the net. 
This can include 200 or more stations 
at once. Each message you type can 
be routed to all of the other packet 
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What is Packet? 


stations (that are checked in) at once 
or you can select to type to an indi- 
vidual station. You in turn will see 
all of the Dx spotting reports typed 
by the other hams that are tied in. 


Packet is a computer based com- 
munications method. This means 
that your communications can take 
some advantage of the power of the 
computer. For instance your packet 
station could be used as an excellent 
selective call device. You can leave 
your station on all of the time and 
when another ham calls you your 
station can inform you. Thus you 
take notice of only that activity which 
is directed at you. (You can also set 
it up to monitor other local activity.) 
Using the latest TNCs that have built 
in message storage called Personal 
Message Systems you can have your 
friends leave messages for you when 
you are not in. Your TNC will tell 
you that there is mail waiting with 
a signal lamp. 


What do we 
need to packet? 

There are 3 basic parts to a packet 
radio station: A radio system, a dis- 
play/entry device, and a packet ra- 
dio TNC. Lets cover each in turn. 
Radio 

The radio system looks a lot like 
a base station 2 meter FM setup. The 
only real difference is that you don’t 
need the microphone to do packet. 
Note that VHF packet can be done 
on 220 or 440 in some areas as well 
and we'll mention HF packet in an- 
other article. Like any other aspect 
of ham radio QRP is not as easy to 
use for a beginner. The ideal station 
would be a low power 2 meter sta- 
tion (1 watt) with a small beam but 
until you get used to packet and what 
is out there I recommend that if you 
can arrange it that you start out with 
a 25 watt station and a good base 
station antenna. In some areas a 
handie talkie will perform perfectly. 


Computer or dumb terminal 
The display/entry device can be 
anything from a simple computer 


system like the Commodore 64 to a 
“dumb” CRT terminal to a more 
elaborate computer system like a PC 
clone or Macintosh. The computer 
must have a TTL serial or RS-232 
interface and you must have a com- 
munications program to run on it. A 
computer with a disk drive will al- 
low you to store your conversations 
or received text and may also let you 
use some of the more powerful or 
sophisticated packet modes. A 
“dumb” terminal may be found in the 
surplus market for $30 or so (for 
instance flea market specials). 


TNC 

The packet radio TNC is the real 
key to the operation. This “T'NC”, 
which means Terminal Node Con- 
troller, is a computer device itself that 
takes care of all of the dirty work 
involved with packet communica- 
tions. The TNCs range in price from 
about $115 to about $400. The 
cheaper TNCs are just as good for 
VHF packet radio as the more ex- 
pensive ones. The more expensive 
TNCs offer other digital modes such 


2M Base Station Antenna 


2m FM Tranceiver 


TNC (Terminal Node 
Controller) 

MFJ 1270B, AEA PK88, 
Kantronics KPC2, or 
PacComm Tiny 2 
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= Computer 
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as computer operated Morse Code, 
AMTOR, digital reception of re- 
broadcasted satellite pictures, RTTY 
(radio Teletype), Facsimile, and even 
slow scan television. Consult the 
packeteer of your choice or ham 
magazine for advice on which of the 
models is the better choice! If you 
will settle for VHF packet operation 
only you should not spend more than 
$130 for your TNC. 


How does it work? 

Packet radio allows the digital 
transmission and reception of mes- 
sages in small chunks called pack- 
ets. At avery basic level it takes the 
characters in each message and 
translates each character as a se- 
quence of high tones and low tones. 
Each letter consists of 8 bits, each bit 
can be a high tone or a low tone. The 
letter is preceded by a high tone and 
followed by a high tone (Start bit and 
Stop bit). A letter “C” sounds like: 
high lo high lo lo lo lo high high high. 
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The tones all run together with no 
silence in between and on amateur 
packet radio the total length of a 
single character is about 10/1200ths 
of asecond. That’s ten bits at 1200 
bits per second. This means that a 
message with one hundred and 
twenty characters could be sent in 
one second. 


Addresses 

Now comes the nifty part. Each 
packet includes, at the start of the 
packet burst, the callsign of your 
station and the callsign of the des- 
tination station! That means that if 
you chose, your station can reject any 
packets that are not to you. Secondly 
each packet station only transmits 
for long enough to get across its short 
message. Thus several hams can use 
a single frequency for conversations 
without having to listen to each of the 
other conversations. 


In normal packet operation you 
would type a carriage return after 
each line of text that you are send- 
ing to another station. After you type 


the carriage return your packet 
station will wait for a quiet moment 
on the frequency and then send its 
message. If you have specified an 
intermediate station in the path to 
your friend then the intermediate 
station will hear its call in your 
message and will retransmit your 
message, only if the message is re- 
ceived perfectly and after the inter- 
mediate station sees the frequency 
quiet. Then your friend’s station will 
hear the message and send back an 
acknowledgment which is picked up 
and echoed by the intermediate 
station. When your station gets the 
acknowledgment it will go on and 
send your next line of text when you 
hit the next carriage return. If you 
have already hit the next return then 
your station will immediately start 
looking for the frequency to get quiet 
and will the transmit the next line. 
If your station waits for a preset 
amount of time and doesn’t get an 
acknowledgment for its packet it will 
send another one. This will repeat 
until the message gets through or 
your station sends RETRY amount 
of times, (usually 10). The form of 
communications where your station 
waits for a quiet moment and then 
transmits its message is called 
“Carrier Sense - Multiple Access” or 
CSMA. 


Digipeaters 

By the way, you can specify up to 
8 stations as intermediates and your 
message will be echoed by each in 
turn all the way to the destination 
station. Each intermediate station 
is called a "digipeater”. Any station, 
including yours, may be used as a 
digipeater by another station, merely 
by specifying your station’s call as an 
intermediate. Except for emergen- 
cies or when no other resource is 
available you should not use digi- 
peating. See Hidden Transmitter 
Syndrome and Using a TheNET 
Network. 


How do we use it? 
Your packet TNC operates in 2 
modes: Command mode and Con- 
verse mode. In Command mode you 
can instruct your TNC about its op- 


eration, its callsign, RETRY value or 
whether it MONITORs the channel 
or listens only to messages with its 
callsign. Additionally you can com- 
mand your TNC to connect to an- 
other station. It is in the connect 
command that you specify the des- 
tination callsign and the callsigns of 
any intermediate stations. 


In Converse mode anything you 
type will be sent over the air when 
you type a carriage return. If you are 
connected to another station the TNC 
will send the message and wait for 
an acknowledgment or retry as de- 
scribed above. If you are not con- 
nected to another station your TNC 
will send the message as soon as the 
frequency clears and will not wait for 
an acknowledgment. This is called 
unproto or non-connected mode and 
is useful if there are other stations 
MONITORing the frequency. This 
is how you may call for any contacts 
(for instance calling CQ). From 
command mode you can tell your 
TNC to use a digipeater during un- 
proto transmissions using the UN- 
PROTO command. More detail on 
this process is covered in Operating 
a Packet Station. 


Anything Else? 


Glad you asked. There are many 
ways to play with packet. Some 
hams set up automated stations 
(called servers) which allow con- 
nection by other hams. You may 
then connect to an automated station 
and command it to perform many fun 
and useful functions. Among the 
most common sort of automated 
station is the packet bulletin board 
or PBBS, also known as a “mail box”. 
These stations allow a packeteer to 
connect up and send and read mes- 
sages. Each message is usually up 
to about 2000 characters long but 
sometimes 10,000 or more. The mail 
box lets you look at any messages 
that are listed as bulletins. You can 
send messages to other stations and 
you can read messages that are to 
you. You can also send bulletins. 
(This is covered under A Beginner's 
Guide to Servers) 


—KA2DEW ; 
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Operating a Packet Station 


At present there are several different brands of packet 
controllers and many kinds of software, both in the packet 
controllers themselves and that will run on personal 
computers. This article can not attempt to cover all forms 
of packet software and hardware combinations. Instead 
I'm going to address the specific software that the Tucson 
Amateur Packet Radio club produced. This software is 
identical to that which PacComm and MF ship although 
both of those companies offer enhanced versions. AEA 
and Kantronics use a similar (but not exact) software 
in their simpler packet controllers. Please consult your 
owner's manual for the details. 


Hook up the packet station. You'll need a 2m radio 
and antenna. To find a frequency to operate on you 
should consult the packet maps, ask somebody or if all 
else fails dial your radio around in the range of 144.91 
through 145.09. If you can get a S9 or better signal on 
one of those frequencies you are probably all right. Figure 
out what frequency you want to try first and note it. We'll 
get back to the radio in a few inches. 


If you can get the callsign of somebody that is within 
range and the frequency they'll be on, that would be 
advisable. 


You'll need a cable to plug your TNC into your radio. 
For your first attempt it is advisable to connect the TNC 
to the earphone/external speaker jack on the radio, as 
well as to the microphone connection. Some radios have 
audio available on the microphone jack and others have 
it on an accessory jack on the back of the radio. The 
reason that you'll want to start with the earphone/ex- 
ternal speaker jack is because you definitely have volume 
control of that audio and it is definitely going to have 
the range (both loud and quiet) that you'll need. Most 
TNCs come with enough information to make that cable. 
You will also need the pin-out of the microphone con- 
nector on your radio. If you don't have the documenta- 
tion for the radio you may have to take the microphone 
apart to figure it out. The connections in the mike 
connector you'll need are PTT (ground = active), Mi- 
crophone audio, and Ground. Most TNCs have a receive 
squelch signal input but you won't be using that now. 
Make sure you have ground connected to the earphone 
plug as well as to the microphone plug. 


Plug the TNC into power with the TNC to radio cable 
disconnected on both ends. Dial the radio to a known 
quiet frequency or disconnect the antenna. Turn off the 
radio. Turn on the TNC. The TNC should power up 
and indicate so via it's LEDs. The PacComm Tiny 2 and 
the MFJ 1270B will light up three lights as soon as the 
power switch is pushed in. Within 5 seconds two of the 
three lights will simultaneously go off. This means that 
the TNC is working. Now turn on the radio. Since the 
radio is not hearing anything the S meter should read 
zero. Open the squelch so that you hear the FM rush- 
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ing noise. Turn the volume all the way down while 
leaving the squelch open. Now plug the TNC cable into 
the TNC and into the earphone jack of the radio. At this 
point only one LED should be lit on the TNC (more LEDs 
on the PK232, KAM, PK88). Adjust the volume on the 
radio upwards until the DCD LED lights up. That means 
your Receive Audio and Ground leads are correctly 
connected. Adjust the volume such that it is right at 
the point where the DCD LED just turns on. It should 
either be flickering or solid on. There are some radios 
where this procedure does not work, the Midland 13- 
500 and 13-509 are two that I've had this problem with. 
If that is the case you'll have to guess at the volume 
setting. It's lower that it would seem to need to be. The 
volume and DCD flicker alignment procedure is actu- 
ally the best we can do without an oscilloscope and taking 
apart the TNC. You don't have to be that picky. 


Now close the squelch until the DCD light goes off. 
You'll want the squelch open enough that you can 
definitely copy the station you'll be talking to. In general 
the only station you need to be able to talk to direct is 
the packet node you'll be accessing the network with. 
In some cases, however, you'll want the squelch fairly 
loose so get used to setting it right at the point where 
the DCD light goes off. 


Now hook up the radio's antenna and set the frequency 
to where you'll be communicating. Your RF side is now 
ready. 


Hook up the computer or dumb terminal to the TNC. 
With PacComm TNCs the default baud rate is 1200 
bauds. The MFJ 1270B is set with dip switches on the 
back. Be careful moving the dip switches, it's pretty easy 
to rip the switch from the PC board, it's only soldered 
down and is not attached to the case. Hold it with one 
finger while moving the switches with a pen or small 
tool. One safe way is to put the face of the TNC on your 
knee and hold just the switch with one finger, then make 
adjustments. It's not that it is really that touchy put it's 
a real bear to replace or even to spot that that's the 
problem. Note: If you have an aging MFJ TNC that seems 
to work on the RF side but doesn't talk to your CRT termi- 
nal, check the switch. 


So, set your terminal program or CRT terminal to 1200 
bauds or what you have the TNC preset for. Now power 
the TNC off and back on. Just as the two lights on the 
front panel wink off the TNC should send your screen 
should get about five lines of text indicating the revision 
of TNC software and the manufacturer. 


Type a single carriage return. The TNC should echo 
with a cmd:. If you type another carriage return you 
should get another cmd: on the next line. If an extra 
line is used or if the cmd: is on the same line as the 
previous one then you'll want to play around with your 
CRT terminal or terminal program on your computer. 
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Now type my KA2DEW (use your own call!) and then 
a carriage return. The TNC should come back with some 
kind of acknowledgment like: was NOCALL or some- 
thing like that. You should have another cmd: prompt. 
Now type M and areturn. The TNC will come back with 
MONITOR is OFF or MONITOR is ON. Monitor is 
a feature by which you can see what is happening on 
the frequency you have selected. You'll want to read up 
on monitor in your TNC manual. If you type DISP M 
and a return the TNC will tell you the status of all of 
the monitor options. MH is another useful command. 
Try it. If it displays a list of callsigns then you have 
selected a busy frequency. Each time you see a new 
callsign on the screen it should be added to the MH 
(mheard) list. 


Now we're going to try connecting to the station of your 
choice. If you have a friend that is within range, and 
can get on packet while on the phone with you then call 
them now. 


The command to start a conversation is C CALLSIGN 
where CALLSIGN is the call of the friend or of another 
station you can hear. Let's assume that you are within 
range of a station whose callsign is KA2EIA. We'll have 
a conversation with him and then go back to monitor- 
ing the channel. 


This turns off monitor 
mode. n means no. 


cmd:m n <return> 


MONITOR was ON 
cmd:my <return> Just to be sure we 
did this before 

Good. It's correct. 
Here's where we start 


the connect sequence. 


MYCALL is KA2DEW 
cmad:c ka2eia <return> 


*** Connected to KA2EIA 


Great. That means that you can have a conversation 
with KA2EIA. What Connected to means is that your 
packet station now has KA2EIA's callsign in memory. 
Let me back up a short way and give you some more 
basics. 


The TNC has several modes of operation. Some of the 
modes are independent of others. I'll list them here and 
try to explain what they mean. 


¢ Command mode 

In Command mode when you type something and 
follow it with a return the TNC will inspect what you 
typed and try to interpret it as acommand. M, MH, MY, 
C are all commands, meaning Monitor, MHeard, MYcall 
and Connect. Each time you type a return while in 
command mode the TNC will respond with a cmd: and 
sometimes a message in answer to your command. The 
only exception to this is when you use a command to go 
to another mode. 


¢ Converse mode 
In Converse mode what you type is intended to go to 
another station. You can get into Converse mode from 
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command mode by typing conv return at the cmd: 
prompt. Most TNCs also let you type k return. To get 
back to command mode from Converse mode you can 
type control C (also written as “C) which means that 
you hold down your Control key on your keyboard and 
type a C. It's almost the same as shift C but it's con- 
trol C. 


¢ Monitor mode 

Monitor mode means that you have Monitor turned 
on in your TNC. Monitoring can be done in both Con- 
verse and Command. There are other TNC commands 
that control whether monitoring is done when connected... 


In addition to these 'modes' there is also a Connect 
status. You can either be Connected or Disconnected 
or in the process of getting connected or getting dis- 
connected. 


¢ Connected 

This means that you are connected to another station. 
If you go into Converse mode while Connected anything 
you type on the keyboard, followed by a return, will be 
sent to the connected station. The connected station is 
expected to acknowledge a connected mode packet. If 
no acknowledgment is sent then your TNC will retry. 


¢ Disconnected 

When disconnected if you go into converse mode and 
type something it will be sent out over the radio, just 
as in connected mode. The difference is that the TNC 
does not expect an acknowledgment for each transmit- 
ted packet. The callsign used for disconnected or 
‘Unprotocalled' transmissions is set by the UNPROTO 
command. ' 


Back to where we were. Since we got the *** Con- 
nected that means we are now connected to KA2EIA. 
We are also now in Converse mode. When we type text 
in converse mode while connected it will be sent to 
KA2EIA. We can temporarily go back to Command 
mode, even while connected, by typing a control C. To 
disconnect from KA2EIA we must go to Command mode 
and then use a D command. D means Disconnect. Us- 
ing aC command with no callsign will ask the TNC what 
the current connect status is. The answer may be 
Connected to KA2EIA, Disconnected, Connect in 
progress, Disconnect in progress. 


So, from where we left off: 


*** Connected to KA2EIA 

Hi Tadd, I'm talking to Fred on the 220 repeater. 
OK Steve. I'll type, you can read when you're 
free. | just got home from work and found the 
antenna on my front porch. | looked through the 
junk and can only find 4 of the boom to element 
clamps. | think I'm missing the one for the 
driven element. Was that part of the package? 
OK, I'm clear on 220. The driven element clamp is 
part of the T-match assembly. That's part of the 
mess that is in the paper bag. Did you get that 
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or did your St. Bernard get that? hi 

Ah. Paper bag. Under the pulley and rope? 

Yep. You got it. 

Here it is. What a mess. 

Yep. Last year at field day it got away from us. It might have 
been wise to remove the coax before tipping the tower over 
eh? 

Sure thing. I'll get to work on it. 

Brap at you later. 


cmd:D 
*** Disconnected 


Notice how at the end of the conversation we did a 
control C and then a D for disconnect? That's the nor- 
mal way of breaking communications. 


Now let me give you an example of a bad connection 
under noisy conditions. 
cmd:c ka2hcl 
*** Connected to KA2HCL 
Hello Ken? 

*“* Retry Count Exceeded. 
AC 
cmd: 

What happened here is that we got the connect to 
KA2HCL but never got an acknowledgment for the "Hello 
Ken" text. What Ken probably saw was a *** Connected 
to KA2DEW and then nothing after that. If Ken typed 
anything back eventually he also would get *** Retry 
Count Exceeded. 


By watching the LEDs on your TNC you can make a 
pretty good guess as to how communications is going. 
The STA LED is lit when you have typed something and 
it hasn't gotten acknowledged yet. If this is the case it 
doesn't do any good to type anything more. Your TNC 
will buffer everything you send but only while you are 
connected. If you send a long diatribe at the station you 
are talking to and you get disconnected only after typ- 
ing a lot you may have wasted words. This can be dis- 
appointing. 


In the sections on servers and use of the network we'll 
explore other things that we can do with packet. Key 
words: Don't get frustrated. Call somebody and talk 
about it. If you learn something that you think is critical 
to the newcomer experience but that isn't in this book, 
write it down. By all means talk to the editor and see 
that it gets in here. 73 and see you on packet! 


—Tadd, KA2DEW 
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Beginners Guide to 
Understanding Servers 


A server is a device that serves remote users, in this 
case - you. That's pretty vague I know. That's because 
servers can be so many different things. In a vague way 
your TNC is a server to you. It all depends on what you 
call remote. For our purposes a server is something that 
you will access via packet radio from your station. 


Command Line 

All servers on packet radio use a device called a 
command line. A command line is a mechanism where 
a person can use a keyboard to type a one line com- 
mand. When a computer is expecting a command line 
command it will wait until it sees a carriage return 
character and then will look at what characters preceded 
the carriage return. A command line is usually associated 
with a prompt. A prompt is a text message that tells 
you that it is time for you to type. The cmd: prompt on 
your TNC is a good example. Each time you see a cmd: 
prompt you may type a command. That is called a 
command line. The process by which your TNC analyses 
your command is called a command line interpreter. 


When you tell your TNC to connect to a server it makes 
your keyboard the control for the server's command line. 
That means that if you type something and hit a return 
what you type will be sent to the server and the server 
will try to figure out what you mean. Figuring out what 
you mean is actually pretty simple because servers have 
a very limited list of things they will expect. If you type 
something that the server doesn't expect it will usually 
give you a simple error message to tell you that what you 
typed was meaningless to it. It may tell you that what 
you typed was meaningless even if you only missed by 
one character. When you type something that is one of 
the things that the server expects it is called a command. 
You are commanding the server to do something. 


Many of the commands that a server expects are things 
that the server can do immediately. For instance you 
can tell the server good-bye usually with a B command. 
Just type B and a return. When the server gets the B 
command it will disconnect from you leaving you with 
a *** DISCONNECTED on your display. 


Disk Drives 

A disk drive is a computer accessory that stores data 
in the form of magnetic impulses on a flat media that 
is much like an extremely high quality magnetic re- 
cording tape. The density of data is high enough that 
one thousand billion characters could be stored on a 
surface that is measured in tens of square inches. Ac- 
cess time to that data can be as fast as a hundredth of 
a second and the data can be read off the disk at millions 
of characters per second. The particular type of disk drive 
I'm describing here is called a hard disk because in or- 
der to get that much data on so small an area the re- 
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cording surface has to be very flat and in order to get 
the data on and off the disk so fast the disk has to spin 
very fast. 


A disk drive is an accessory to many computers, even 
cheep ones. The disk drive I was describing above costs 
about $1000 but drives which are somewhat slower and 
which store less data can cost as little as $200. Amateur 
radio operators can have a computer system with a hard 
drive for around $450. 


There are many things that hams can do with such 
acomputer. One of the things we can do with a computer 
that has a hard drive is make it possible for packet users 
to store and retrieve data on the drive from over the radio. 
Such a computer system is called a server. 


Servers 

Most servers are computer systems that have a hard 
drive and which allow hams to connect in via packet. 
Once connected the ham gets a prompt and can type 
commands on a command line. The server interprets 
the commands and responds. Many of the commands 
allow the ham to write text to the server's disk drive or 
read text from the disk drive. Here is a brief run down 
on what some of the servers do: 


Bulletin Board Systems (BBS) 

These servers allow a user to send messages to other 
users, to read messages and to send and receive bulletins. 
Messages and bulletins may be sent to users that use 
the same BBS and to those who use other BBSs. 
DxCluster 

Users connect and stay connected. When a user of 
any DxCluster hear a rare Dx station they post it to the 
DxCluster which copies it to all of the other DxClusters. 
DOSgate 

Users connect and then use the programs that the 
DOSgate operator have available. These include satellite 
tracking, VE exam simulation, repeater directories, 
games. 

Callbook Server 

Lets a user reference a computerized amateur radio 
callbook. 

CROWD converse node 

Several users connect and have a multi-way conver- 
sation. 
NOS 

Users access a NOS server and then can utilize TCP/ 
IP to access other TCP/IP systems. 

Bulletin Board Systems 

The most common server used in amateur radio to- 
day is called a Bulletin Board System, or BBS. A BBS 
is one of many servers that is commonly made out of an 
IBM PC compatible computer. A BBS has an external 
connection to talk over packet radio to other BBSs and 
to users. The BBS also has a disk drive which allows 
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the storage of messages and text files. Users connect 
into the server over packet radio and with the command 
line prompt may read messages and text files. They may 
also send messages to other packeteers and create text 
files. 

The first of the packet BBSs was created by Hank 
Orenson, WORLI. The program that Hank wrote started 
with a simple command line and a few functions. The 
functions were as follows: 


S_ callsign @ otherbbs Send a message to station 
callsign and deliver it to BBS otherbbs 

list messages 

msgnum Read message msgnum 

Read the Info file 


disconnect from BBS. 
When the user connects to the BBS they get a wel- 
come message that is created by the BBS operator. It 
might look something like this: 


COS ee ate 


cmd: c w3iwi 
*** Connected to W3IWI 
Welcome to Tom's BBS in Baltimore MD. 
Use the | command to get information about the BBS. 
KA2DEW de WSIWI B,I,L,R,S> 
To send a message to somebody else the user would use 
the S command: 
s ka2eia 
Enter a title for your message: 
Trying new BBS 
Enter your message. Type control Z on a blank line to end 
your message: 
Steve, 
You finally talked me into getting on packet radio. | 
hope this works. 
How often do you check into Tom's BBS to get mail? 
Tadd 
OW A 
message Stored as #215 
KA2DEW de WSIWI B,I,L,R,S> 
To read the message Steve would connect to the BBS 
later and do an L command which showed all of the 
messages on the board. 


One of the features that made Hank's software popular 
was that a ham could connect to one BBS and send a 
message to a ham at another BBS. The BBSs had text 
files on disk called forward files. This file had a list of 
the other BBSs and a simple script that told the BBS 
computer what it had to do to get a message to the other 
BBS. Basically what the BBS did was the same thing 
that a user would do. It would do a connect to the other 
BBS and then use the S command to send the message. 


As experimentation allowed and as the program got 
popular Hank added commands and features to the 
program and tried new things. The list of commands 
expanded from the simple few to hundreds. The user 
interface (the list of commands and the way the command 
line works) stayed very similar. 
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Originally Hank wrote is program for a computer that 
Xerox produced as a work processing system and which 
Xerox had discontinued. There were scads of these 
computers available for a few hundred dollars which was, 
at the time, considerably cheaper than most personal 
computers. Once clones of IBM's PC started showing 
up on the market for around $1000 other writers of BBS 
programs published their contributions. The first of these 
was WB8MBL. Later WORLI converted to IBM com- 
patible PCs. In the seven or so years since then many 
more authors published their contributions. One very 
nice thing about the BBS servers, which was started by 
Hank, is that all of the software has been free. The 
software authors have had take public approval and user 
feedback as their only reward (except for infrequent 
donations). Actually, except for very few exceptions, all 
software for amateur packet radio has remained free. 


If you are interested in obtaining a copy of the current 
run of BBS software you have only to telephone one of 
the many telephone BBSs. Look for articles announcing 
the release of new software elsewhere in this Notebook 
and in future issues of the Dedicated Link. For user 
information on just about all of the BBSs you need only 
connect to the BBS and make use of the extensive HELP 
facilities on any of the BBSs. Some also have 
Downloadable files for users. 


DxCluster 

Around about 1987 AK1A, Richard Newell, created 
the PacketCluster™. This is a computer software pack- 
age which runs on a PC to implement the DxCluster. 


The primary purpose of a DxCluster is to relay im- 
mediate rare Dx spotting information between stations. 
Packet stations connect to the DxCluster and stay con- 
nected for long periods while they are at their HF sta- 
tion. When they hear a rare country on CW or SSB they 
type a single command into their packet station which 
is relayed to all of the other connected packet stations. 
A ham operating HF may see a Dx spot come through 
from the DxCluster and will tune to the specified fre- 
quency on the HF radio and work the rare station. 


The secondary purpose of a DxCluster is to be a re- 
source of HF operating information, including callbook 
information, propagation forecasts and other HF DXing 
data. 


The neat thing about DxClusters is that a DxCluster 
may make a full time connection to other DxClusters 
and share information. When a Dx spot is entered at 
one DxCluster it is processed and passed to all of the 
other connected DxClusters. In a system of dozens of 
DxClusters over several states, hooked together via 
quality network links like those specified elsewhere in 
this book, a Dx spot may be entered and will be past to 
the far end of the DxCluster network in a matter of less 
than a minute or so. This means that the information 
is still current when it gets out to as many as 500 or so 
HF stations. 


Abbreviated DxCluster Command List 


(Thanks to K6LLK) 
Command Description 
Announce Make a general announcement to all nodes 


Make a general announcement to local node 


Bye Bye, disconnect from the PacketCluster 
Conference Enter network conference mode 
DELETE Delete mail message 
Directory Show active mail messages 

Show All active mail messages 

Show mail to or from yourself 
Dx Make a DX spotting info announcement 
Show Dx Show a Dx spotting announcement 
Help or ? Help (displays this listing) 

Display help for a particular command 
Read Read a mail message 
Reply Reply to the last-read mail message 
Send Send a private mail message 
Set Set user specific parameters 
Show Display various DxCluster Databases 
Talk Talk to a specific station 
Type Display a particular file 
Update Update a database 
Upload Upload a general file 

Upload a bulletin file 
WWV Make a WWV announcement 


Show WWYV announcements 


Syntax 


DX freq call 

SH/DX 

H 

HELP command 

R msg# 

REP msg# 

S call or S/P call 

Example: SET/Name Tim 
SH/commands. 

T call 

Example: TY/BULLETIN CMND.TXT 
UPD/Data 

UPD/File 

UPD/Bull 

WWYV SF=xxx, A=xx, K=xx,forcast 
SH/WWV 


This material was copied from the Fall 1990 edition of the NCPA Downlink 
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Since many DxCluster systems may be connected in 
a network the facilities of all of the DxClusters are 
available from any one DxCluster. The commands 
available on the DxCluster allow easy access to all of 
these facilities without burdening the HF operator with 
having to learn much about the network. 


See the side-bar for a short table of Pavilion Software 
PacketCluster™ commands. 


DxCluster operation is currently available with two 
software packages. MSYS, which is free and which is 
available on many of the telephone BBS systems and 
AK1A's version which is marketed as PacketCluster™ 
by Pavilion Software. 


PacketCluster™ is about $150. Updates are available 
for around $100 when they become available. The cur- 
rent version, by the way, is 5.4-25. K1EA, who is one 
of AK1A's neighbors almost, has been beta testing 5.6- 
00. PacketCluster™ from Pavilion Software is not cheep 
but the support is excellent. 


Pavilion Software 

PO Box 803 

Hudson MA 01749 

508-779-6527 
There is a telephone BBS in California available to 
support PacketCluster™ owners: DxBBS at 916-992- 
0923 


When a user connects to a PacketCluster™ the user 
gets a message that the system operator has programmed 
and then gets a prompt just like in the BBS software 
above. The command set is different of course but you 
can play with it and it will be fairly obvious. 


MSYS is available from most telephone BBS systems 
that support amateur radio products (See the list pub- 
lished in the Dedicated Link). The commands for MSYS 
are published elsewhere in this document. 


DOSgate 

Another useful automated station is called DOSgate. 
This is a program written by NM1D, Rich Bono. This 
program is run on aIBM PC clone and allows a packeteer 
to connect up and use the PC as if it were his own sta- 
tion. You can run programs and even create files. It 
also serves as a packet mail box. Some of the programs 
circulating that are commonly found on DOSgates in- 
clude 


¢ automatic FCC testing sessions that use the real FCC 
test elements to let you practice a license exam. This 
is great for getting new licensees used to the idea of 
passing their first test. 


¢ satellite tracking program to let you see when each 
of the current satellites will be above the horizon and 
what beam headings to use. 

¢ games like Zork and Wumpus 


* amateur radio callbook. This may include your local 
call district or the entire FCC and DOC database. 


When a user connects into DOSgate he gets a mes- 
sage that the system operator has created, followed by 
a prompt which is very similar to a PC DOS prompt: 


C:\HAMRADIO> 

The user can type a PC DOS command, like CD or 
TYPE, or the user can type the name of a program that 
the system operator has put onto the DOSgate system. 
The program can be any PC DOS program that gener- 
ates straight text. No graphics and no screen format- 
ting is allowed. 


I have had conflicting reports about the availability 
of the DOSgate program. When I first heard of DOSgate, 
it was free. I've seen it downloadable form various tele- 
phone BBSs. I've heard that it was an inexpensive for- 
sale program, however. The best bet is to contact NM1D 
directly using NM1D @ WB1DSW.nh. Please get back 
to your editor if you have better information. 


CROWD Nodes 
These are covered in another section. 


NOS 

NOS means Network Operating System. NOS is a 
program which operates as a server to other packeteers 
and as an operating console for the local user. The pri- 
mary purpose of NOS is to be the operating program for 
a local user to communicate with other stations using 
TCP/IP. NOS is not an amateur radio-only program. 
The name NOS is used to refer to many different pro- 
grams which perform file access, keyboard and display 
control, and TCP/IP communications for several differ- 
ent kinds of computers. 


For amateur radio users NOS can be used as a gate- 
way between TheNET users and TCP/IP users, and can 
be a platform onto which new servers can be built. For 
instance, in Oregon, WG7J has created a version of NOS 
which supports a very nice BBS program. In New York 
the members of the RF Harris ARC have create a ver- 
sion of NOS which operates as a multi-site round table 
conference server. 


Conclusion 

Servers have one basic thing in common. They all are 
operated remotely by users. Beyond that anything goes 
and we're only limited by creativity, enthusiasm, and 
time. 


If you hear about something new, send a letter or 
packet gram to NAPRA. 
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TNC Buying Guide 


Terminal node controllers come in several forms. The 
evolution of these controllers may be of interest as it 
simplifies the mystery as to why some controllers look 
the same even though they are from different manu- 
facturers and as to why other controllers are so wildly 
different. 


The furthest back we have to go into TNC development 
in order to make sense of what exists today is the be- 
ginning of the Tucson Amateur Packet Radio club. TAPR 
produced a TNC model based on a Motorola 6800 Mi- 
croprocessor, in 1983. The unit cost $369 as a kit, not 
including the aluminum chassis. The PC board that 
TAPR had designed included an AC power supply which 
was required in order to get the plus and minus 12 volt 
levels need for the serial port. TAPR would sell the rights 
to manufacture the unit for a small sum to any and all 
who wanted it. TAPR’'s purpose was to get companies 
competing against each other in the manufacture of these 
units. AEA and Heathkit took them up on it and started 
marketing TNCs which looked almost identical to the 
TAPRTNC. The price tag for the Heathkit TNC kit was 
comparable to the TAPR price. AEA's was a hundred 
or so more, as a finished product. All three TNCs in- 
cluded a complex front panel LED display and features 
like Morse ID and Vancouver protocol support. A year 
later Kantronics appeared on the scene with a much 
cheaper model which was also based on the TAPR but 
using more modern, and fewer, components. The 
Kantronics KPC-1 cost around $250 as a finished product 
and operated with DC or using the included wall pack. 
The KPC-1 had only three LEDs on the front panel and 
used a simpler, but as powerful, microcomputer. The 
KPC-1 could run on a single voltage DC supply. The 
commands that the 4 TNCs understood and the way they 
were operated was almost identical. 


In April of 1985 TAPR announced a new TNC called 
the TNC 2. TAPR wanted to get the price of a TNC down 
much lower. The TNC2 was a much simpler unit in 
terms of components but more powerful in that it took 
advantage of ICs which, in 1985, cost five dollars or more. 
The TNC 1 (as TAPR's first TNC was now called) was 
based on more, cheaper, components. 


The TNC2 looked very much like the Kantronics KPC- 
1 but went in a totally different direction with it's mi- 
crocomputer, being based on a Z80 chip instead of the 
Motorola family of micros as had the four previous TNCs. 
In addition the TNC2 used a cute charge-pump power 
supply circuit for the serial port so it could run on 12 
volts and not have the plus and minus supply require- 
ment. The TNC 2 was introduced at $249 in kit form. 
TAPR did an interesting thing here. Unlike the TNC 
1 which was sold for a few years by TAPR when the TNC 
2 was introduced TAPR announced that they would only 
make 1000 of them. The phone would open at noon and 
have your credit card ready! For three days the Tuc- 
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son telephone system was brought to it's knees!! De- 
livery of the TNCs would occur over a 5 month period 
at which time TAPR would stop production of the kit. 
Again TAPR was pushing for manufacturers to pick up 
the product. This time the manufacturers did so, and 
with a vengeance. 


AEA, MFJ (existing amateur radio accessories 
manufacturers) and GLB (existing amateur radio RF kits 
manufacturer) all introduced TNCs which were very close 
to the TAPR model. All were priced about the same as 
the TAPR. PacComm was founded in Florida to 
manufacture TNC 2 clones. The price war was on. 
Within 2 years (1988) TNCs were down to $130. Now 
the war moved to bells and whistles. Multimode TNCs 
and built in mailboxes started appearing. Next came 
reduced power requirements and small size. TNCs which 
were built on PC compatible plug-in cards came out. 


More recently hobbyists have cost reduced packet radio 
to around $50 for hams who already own PC compatibles 
by creating TNCs who's digital section would use the 
PC compatible. These TNCs are just a modem chip on 
a board that plugs into the PC's serial or parallel ports. 
They are called Baycom and PMP. (Poor Man's Packet). 


One feature which appeared on the scene in the last 
couple of years is the internal mailbox mentioned above. 
This allows the TNC owner to leave messages in the TNC 
memory for friends to get when connecting in from over 
the radio. The friends can then leave messages for the 
TNC owner. It is also possible for a BBS system to 
forward messages to the TNC and to pick up messages 
from the TNC that are out bound. This means that the 
TNC owner need not connect to the BBS to send and 
receive forwarded mail. The TNC will flash an LED to 
indicate that mail has been received. 


As of 1992 we have quite a collection of TNCs to pick 
from. I can make recommendations but in truth I don't 
have all of the information. What I'll do instead is to 
tell you what I know and hope that when you learn better 
that you'll get back to me. 


There are five categories of TNCs that deserve a look: 
¢ Stand-alone VHF-only 

Stand-alone VHF/HF deluxe multimode 

PC compatible internal (plugs inside computer) 

Modem only, Software TNC (requires computer) 

Stand-alone Micro-size and Micro-power 
Unfortunately this book needs to get done and docu- 
menting all of the TNCs on Earth is a good way to see 
that it doesn't. So, for most of the existing TNCs I'm | 
only going to be able to mention their existence (if even 
that). I have only owned and operated a few of these 
and am dependent on contributors for the information. 
Thus the coverage of bugs and features isn't consistent. 
Please, if you have experience with TNCs, send me info. 
Also make corrections and criticisms! 
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Stand-alone VHF-only 
¢ TNCs can all be operated on 12V regulated DC. 
¢ Directly plug into the microphone and earphone 
of a single VHF radio 
e Front panel LEDs indicate connect, PTT, DCD, 
power 

¢ Comparable size, 4x1" face x 7" deep 
¢ Comparable power requirements, about 200mA 
e All can be operated easily with dumb terminal or 
computer with terminal emulator 
Use standard cmd: prompt 
Allow multiple connections at the same time 
Internal mailbox connectable by other stations 
Have internal connections for new modems 
Cost about $130 
MFJ 1270B 

The MFJ TNC is available off the shelf from many 
of the amateur radio dealers. Ham Radio Outlet and 
Amateur Electronics Supply are two that sell this unit 
at reasonable prices and with very quick delivery time. 


The 1270B uses the TAPR specified connections for 
power (coaxial bullet connector), serial port (DB25) and 
radio connector (5-pin DIN). The 1270B also has a TTL 
connector for it's serial port to allow compatibility with 
the older computers including the C64 and TI99. 


The 1270B is software compatible with the TAPR 
model so it can be used with any EPROM software that 
is available for that unit, including TheNET, ROSE, KISS 
and DED host mode. With the included software the 
user can, of course, connect into any of the AX.25 net- 
works. Software compatability is only an issue if you 
plan on going inside the unit and play with packet. 


Serial port baud rate is set via a dip-switch on the back 
panel and is adjustable from 300 to 9600 bauds. Radio 
baud rate (only useful with external modem or if used 
without a modem) is setable on the same dip-switch to 
300, 1200 or 9600 bauds. 


Power Supply: 

¢ 12V unregulated, 

¢ 180mA. 

¢ includes wall pack. 

Bugs: 

e the case is thin sheet metal 


¢ the baud rate adjustment switch is fragile and 
will break if abused. 

¢ Once a station is connected to the PMS (Personal 
Message System) the operator of the TNC can't 
talk to that station. You can disconnect to PMS 
user but can't patch over to him. 

Features: 

¢ TAPR2 compatible so you can change out the 
software to be TheNET or ROSE networking 
software, or other new softwares. 

¢ ©Off-the-shelf at many ham radio stores. 

Where to get one: 

Ham Radio Outlet - 1-800-854-6046 
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AEA PK88 

The PK88 is available off the shelf from many of the 
amateur radio dealers. Ham Radio Outlet and Amateur 
Electronics Supply are two that sell this unit at reason- 
able prices and with very quick delivery time. 


The ABA PK88 uses the TAPR specified connections 
for power (coaxial bullet connector) and RS-232 (DB25). 
The radio connection is via an 8 pin mike jack (same kind 
as used on ICOM and Kenwood mobile and base rigs) 
and/or via a mini phone plug. A phone plug to phone 
plug jumper is including allowing immediate connection 
to a radios earphone/external speaker port. Out of box 
to listening to packets is about one minute. 


Serial port baud rate is set in software. When you 
first hook up to the TNC you type the * key over and 
over until the unit answers. That sets the baud rate. 


Power Supply: 

¢ 12V unregulated, 

¢ 180mA. 

¢ includes wall pack. 

Bugs: 

¢ Not TAPR2 compatible software. 
Features: 


¢ Baud rate adjustment is in software, no switches. 

e Extra LEDs for more status indication. 

e Maildrop may be interrupted so the TNC owner 
can directly talk to someone who connected to the 


maildrop. 
e The case is very heavy. 
Where to get one: 


Ham Radio Outlet - 1-800-854-6046 
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PacComm Tiny 2 Mark2 

The Tiny-2 is available at PacComm independent 
distributors (not ham radio stores) and from PacComm 
direct. Delivery time is 2 to 4 weeks. 


The PacComm Tiny 2 uses the TAPR specified con- 
nections for power (coaxial bullet connector) and radio 
connector (5-pin DIN). The Tiny 2 also has a TTL con- 
nector for it's serial port to allow compatibility with the 
older computers including the C64 and TI99. The Tiny 
2's RS-232 connector is the same connector and pinout 
as a PC compatible 9-pin. 


The Tiny 2 is software compatible with the TAPR 
model so it can be used with any EPROM software that 
is available for that unit, including TheNET, ROSE, KISS 
and DED host mode. With the included software the 
user can, of course, connect into any of the AX.25 net- 
works. Software compatibility is only an issue if you plan 
on going inside the unit and play with packet. 


Serial port and radio baud rates are set via a set of 
jumpers inside the box to 300, 1200, 2400, 4800, 9600, 
19,200, 38.4Kbauds. 


Power Supply: 

¢ 12V unregulated, 

¢ 50mA. 

¢ Wall pack not included. 

Bugs: 

¢ the baud rate adjustment is inside the box. 

e Like the other TNCs of this one's class the case 
closures are non-threaded and the metal screws 
will strip if removed and tightened too many 
times. Unfortunately the Tiny 2 is clumsy to 
close once the screws are stripped. 

¢ Once a station is connected to the PMS (Personal 
Message System) the operator of the TNC can't 
talk to that station. You can disconnect the PMS 
user but can't patch over to him. 

Features: 

¢ TAPR2 compatible so you can change out the 
software to be TheNET or ROSE networking 
software, or other new softwares. 

¢ baud rate is setable to 38.4Kbaud. 

¢ available without EPROM and manual for a $20 
cost savings making this the most economical 
unit for network building. 

Where to get one: 

NX2P Electronics - 201-729-6927 


Kantronics KPC-2 
The KPC-2 is a VHF/FM 1200 baud packet TNC with 
additional packet features. 


The KPC-2 uses the TAPR specified connections for 
power (coaxial bullet connector) and RS-232 (DB25). The 
radio connection is via an DB9 which is standard only 
to Kantronics. 


Serial port baud rate is set in software. When you 
first hook up to the TNC you type the * key over and 
over until the unit answers. That sets the baud rate. 


Power Supply: 

¢ 9to 14V unregulated, 

¢ 250mA. 

e includes wall pack. 

Bugs: 

¢ Not TAPR2 compatible software. 

¢ Includes KA node software whose major impact 
on packet radio is to cause hidden transmitters. 

Features: 

¢ Baud rate adjustment is in software, no switches. 

e Extra LEDs for more status indication. 

¢ Includes KA-node software which is very useful in 
emergencies when traffic level is low. 

¢ PMS uses a separate callsign and may use an 
alias as well. Thus the PMS could be accessed by 
KA2EIA-2 or by STEVE. 

Where to get one: 

Ham Radio Outlet - 1-800-854-6046 


Stand-alone deluxe multiport or 
multimode 

Kantronics KAM 

The KAM is a multimode VHF/HF digital communi- 
cations controller including VHF packet TNC mode. The 
KAM can operate VHF packet at the same time as op- 
erating one of it's HF modes, including CW, RTTY 
(baudot and ASCII), FEC, ARQ, and NAVTEX. 


This unit is normally used with a Kantronics program 
running on a PC compatible. 


No price or feature information available at this time. 
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MFJ1278 

Multi-mode controller with AMTOR, RTTY (baudot 
and ASCII), CW, FAX, SSTV (MFJ compatible), and 
NAVTEX. 


Connections include RS-232 and TTL serial ports, 
peripheral I/O port, radio port (probably a TAPR stan- 
dard 5 pin DIN). 


Price: $280. 
Power Supply: 
¢ included AC supply. 
Bugs: 
¢ Not TAPR2 compatible software. 
¢ Operating mode not displayed on front panel. 
Features: 
¢ Baud rate software adjustable. 
¢ Lots of LEDs for status indication. 
¢ Includes personal mailbox function. 
Where to get one: 
Ham Radio Outlet - 1-800-854-6046 
AEA PK232 
The PK232 is a multimode VHF/HF digital commu- 
nications controller including VHF packet TNC mode. 


The PK232 uses the TAPR specified connections for 
power (coaxial bullet connector) and RS-232 (DB25). The 
radio connection is via a 5-pin 0.1 center in-line connector. 
A wired cable with one of these connectors comes with 
the unit. All you have to do is add the connector to fit 
your radios mic connection. An audio in-line is provided 
through this connector, as well as a 1/8 inch mini phone 
jack for connecting to your radios earphone/external 
speaker jack. 


Serial port baud rate is set in software. All you do is 
send a series of ***, and the PK232 will match the 
terminal's speed. 


In addition to packet, the PK232 will run RTTY at 5 
bit baudot code, or 7 or 8 bit ASCII at baud rates from 
45 baud up to 300 baud, with settings for 60 and 100 
words per minute. It will run AMTOR and machine 
Morse Code both send and receive at up to 100 words 
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per minute. (To receive the code needs to have near text- 
book spacing). With the right cables it will also to weather 
FAX. 


Price: $320 

Power Supply: 

¢ 12V, 700mA regulated (not included) 

Bugs: 

¢ Not TAPR2 compatible software 

¢ Loss of power before unit is turned off may totally 
reset the unit 

¢ Internal 14 MHz clock will cause birdy on one 
frequency on 20 Meters. If it falls on your favorite 
frequency, the unit can be modified to move it off 
frequency, but I have not heard of any permanent 
1x. 

¢ Operation of the unit can be so complicated that it 
may be totally baffling for a beginner. A program 
for your computer, to operate the PK232, isa 
must. Such a program is available from AEA at 
an additional cost. 

Features: 

¢ Baud rate software adjustable. 

¢ Lots of LEDs for status indication. 

e Tuning indicator for HF modes. 

e Includes personal mailbox function. 

Where to get one: 

Ham Radio Outlet - 1-800-854-6046 


PC compatible Internal 
These are cards that plug into a PC compatible. Unless 
noted they require software running in the PC to make 
them operate. Sorry for the appearance of PacComm 
favoratism but I got most of this information from a 
chance telephone call. More will flow in the next edi- 
tion of this volume. 


AEA PCB88 

Same features of the PK88 but requires a PC com- 
patible computer. PC compatible plug in internal PC 
card. Has on board processor and external power con- 
nection (12V) so the TNC can operate when the PC is 
turned off. 


Price: not available 
Contact AEA at 800-432-8873 or 206-775-7373 for 
more information. 
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PacComm PC320 

Complete TNC on a PC compatible plug in card. Al- 
lows two radio connections but only one at a time. In- 
cludes HF (300 baud) and VHF (1200 baud) modems. 
Standard modem disconenct header. The PC320 is avail- 
able at PacComm independent distributors (not ham 
radio stores) and from PacComm direct. Delivery time 
is 2 to 4 weeks. 


Both radios connect to a single DB-9, although the 
connections exist for both radios at the same time. A 
shareware terminal emulator program for a PC compat- 
ible is included. A Terminate Stay Resident program 
(run in your autoexec.bat) is included that supplies the 
tuning indictor for HF modem operation. A command 
at the cmd: prompt changes which port is in use. 


The PC320 is powered by an external 12V supply and 
may remain on when the PC is shut down. 
Price: $210 
Where to get one: 

NX2P Electronics - 201-729-6927 
PacComm PC105D 

A modem on a PC compatible plug in card. Allows 
one radio connections or VHF (1200 baud). The PC105D 
is available at PacComm independent distributors (not 
ham radio stores) and from PacComm direct. Delivery 
time is 2 to 4 weeks. 

The radio port connector is ae DB-9s. The unit comes 
with G8BPQ node software and includes the GBBPQ 
terminal emulator. It also comes with "node manager 
software" written by AC4X which operates as a termi- 
nal emulator, as well, using the G8BPQ node software. 

Includes open squelch DCD adapter. (that's what the 
D suffix means) 

There is a 2nd modem port on the PC105D board 
which might be used for a TTL port. This feature is not 
well supported by the documentation. This unit is spe- 
cifically designed to allow you to not use the COM1 and 
COM2 interrupts. 

Price: $120 
Where to get one: 


NX2P Electronics - 201-729-6927 
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PacComm PC110D 

A modem on a PC compatible plug in card. Allows 
one radio connections for HF (300 baud) or VHF (1200 
baud). The PC110D is available at PacComm indepen- 
dent distributors (not ham radio stores) and from 
PacComm direct. Delivery time is 2 to 4 weeks. 


The radio port connector is a DB9. The unit comes 
with G8BPQ node software and includes the GBBPQ 
terminal emulator. It also comes with "node manager 
software" written by AC4X which operates as a termi- 
nal emulator, as well, using the GBBPQ node software. 


Includes open squelch DCD adapter. (that's what the 
D suffix means) 


There is a 2nd modem port on the PC110D board 
which might be used for a TTL port. This feature is not 
well supported by the documentation. This unit is spe- 
cifically designed to allow you to not use the COM1 and 
COM2 interupts. 


Price: $130 
Where to get one: 


NX2P Electronics - 201-729-6927 
PacComm PC120D 

Two complete modems on a PC compatible plug in 
card. Allows two radio connections at a time. One ra- 
dio connection can be on either HF (300 baud) or VHF 
(1200 baud). The other must be on VHF (1200). The 
PC120D is available at PacComm independent distribu- 
tors (not ham radio stores) and from PacComm direct. 
Delivery time is 2 to 4 weeks. 


Both ports are on one DB9Y. The unit comes with 
G8BPQ node software and includes the G8BPQ termi- 
nal emulator. It also comes with "node manager soft- 
ware" written by AC4X which operates as a terminal 
emulator, as well, using the G8BPQ node software. 

Both ports have open squelch DCD adapters. (that's 
what the D suffix means) 

This unit is specifically designed to allow you to not 
use the COM1 and COM2 interupts. 


Price: $160 (call for latest price) 


Where to get one: 
NX2P Electronics - 201-729-6927 
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DRSI PC*PA 
Available in dual port and single port models, this is 
a PC compatible plug in internal PC card. 


Modem-only Computer-required 

These units require a personal computer to operate. 
Some use Commodore 64 computers, others use PC com- 
patible computers. These are generally kits or inexpen- 
sive assembled units costing around $50. The software 
is usually free-ware (no cost) or shareware (pay if you 
are honest) and requires that the computer is on and 
running the program in order for packet to function. 


Tigertronics BayPac BP-1 

This is a PC compatible computer based modem/TNC. 
The TNC plugs into an external port on the PC (not sure 
if it's the printer port or COM/serial port) and operates 
using supplied software. The entire unit is the size of 
the connector that plugs into the PC. Call Tigertronics 
for more details. 


Price: $49.95 for the modem. Software included is 
shareware (I think) and has to be paid for after 
purchase. Check with Tigertronics on this. 

Where to get one: 

Tigertronics Inc - 1-800-822-9722 or 503-474-6700 

MF.J 1271 

This is a Commodore 64 computer based modem/TNC. 

The MFJ modem unit plugs into the computer's cassette 

port and operates both 1200 and 300 baud. The unit 

may be driven by 'Digicom' software (share ware) or by 

the MFJ purchased software. Contact MFJ at 1-800- 

647-1800 for more information. 


Price: $49.95 for the modem, $4.95 for the MFJ 1293 
software. 

Where to get one 
Ham Radio Outlet - 1-800-854-6046 
PMP 

N8KEI and crew developed this one, called Poor Man's 
Packet, in the 1989 through 1990 time frame. This is 
a device which plugs into the parallel port (I think) of 
a PC compatible. 
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Micro-size and Micro-power 
Kantronics KPC-3 
The KPC-3 is the successor of the KPC-2 described 
earlier. The software appears to be slightly enhanced. 
The TNC is not micro sized although it is a bit smaller 
than most of the normal stand alone units. 


Serial port baud rate is set in software. When you 
first hook up to the TNC you type the * key over and 
over until the unit answers. That sets the baud rate. 


Price: $110 
Power Supply: 
¢ 6 to 25V unregulated. 
e 14mA with LEDs off. 
e operates off of internal 9V battery if desired, 
Bugs: 
¢ Not TAPR2 compatible software. 
Features: 
e Baud rate adjustment is in software, no switches. 
e Has "new mail" indicator LED. 
e Has LED indicating someone connected to mail 
box. 

e Some parameters are remotely accessible. 
Where to get one: 
Ham Radio Outlet - 1-800-854-6046 
PacComm HandiPacket 

This is anon-TNC2 compatible TNC. It is low power 
consumption and just slightly bigger than a comfortable 
shirt pocket size. Contact the supplier for more infor- 
mation. Includes internal rechargable NiCAD battery 
which runs it for 9 hours. 


Price $209 
Where to get one: 
NX2P Electronics - 201-729-6927 
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MSYS BBS User Comamnd Summary 


General Commands 


B 


ID 


Jx # 


V 


JD 
JG 


JT 


Log off the PBBS. 


Display hardware configuration of PBBS. 
Display list of the ports, digipeaters, gateways, and 
nodes available on the system. 


Display callsigns of stations recently heard by or 
connected to the PBBS. [optional, port #]. 

Display callsigns of other systems recently heard by 
the PBBS. [optional, port #] {may be disabled by 
Sysop} 

PBBS Systems 

Digipeaters 

Gateways 

KaNodes (i.e.; Kantronics) 

NetRom/TheNet Nodes 

MSYS PBBS’s 

TCP/IP users. 


Display system Message of the Day. 


Enter your name (x) in the system. (10 characters 
maximum). 

Enter your QTH (x). 

Enter your Zip Code (x). 

Enter the callsign (x) of the PBBS where you nor- 
mally receive mail. 


Path last used by a station (x) to connect to the PBBS. 
Path used by the PBBS to forward messages to 
another PBBS (x). 


Page the System Operator so that you may talk to 
him. 


Display list of stations currently connected to the 
PBBS and their current activity. 


Display PBBS software version number. 


Message Commands 


CC#x Senda copy of a message (#) to a station (x). 

K # Kill message number #. 

KM Kill all messages to you that you have read. 

KT # Kill NTS Traffic message numbered #. 

L List new messages since the last time you listed 
messages and then logged off the PBBS using the 
B command. 

LB List bulletins (ALL OF THEM!!!) 

LM List messages to or from you (List Mine). 

LT List NTS Traffic messages. 

LL # List the last # messages. 

LU List messages to you which you have not read. 

L< x List message from a station (x). 

L> x List message to a station (x). 

L@x List messages with a specific coverage area or spe- 
cific PBBS (x). 

L# List messages numbered geater than or equal to #. 
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L #1#2 List messages numbered greater than or equal to 
#1 and less than or equal to #2. 


L”’xyz” List messages with the specified string (xyz) in title. 
{case insensitive} 

L’xyz’ List messages with the specified string (xyz) in title. 
{case insensitive} 

R# Read message number #. 

RH # Read message number # displaying full message 
header and forwarding info. 

RM Read all messages to you which you have not al- 
ready read. 

RN # Read message number # displaying no message 
header information. 

REPly # Send a reply to the author of message number #. 

SB x @y Send a bulletin message to a target audience (x) 
within a specified coverage area (y). 

SP x @y Send a private message to a station (x) at a spe- 
cific PBBS (y). 

ST # Send an NTS Traffic message to the specified Zip 
Code (#). 


Help Commands 


A Abort current process and return to PBBS command 
prompt. 

H Display a short summary of all PBBS commands. 

ix Display extended help information for a command 
(x). 

xX Toggle between short and extended com- 
mand menu (expert mode). 

XF Enable “Fast” mode (>1 line/packet). 

XS Enable “Slow” mode (only 1 line/packet). 

X # Set number of lines (#) to display before pausing. 

* Xxx Enter a comment line (xxx). Useful for replying to 


the Sysop when you get a “Message from Sysop...”. 
MSYS DX Node 


C Enter the MSYS DX Node. Note: May not be 
available on all systems/ports. 

MSYS DX Node Commands 

B Disconnect from DX node. 

BBS Return to BBS. 

C Enter the local conference. 

DX #xz Enter DX spotting data. An HF frequency (#) for 
a DX callsign (x) with any additional information 
(z). 

H List available user commands. 

SH/CL List basic stats about DX network. 

SH/CO Lists DX nodes in the network and users on each 
node. 

SH/Dx/# List last # of DX spots. Default = 5. 

SH/U List local DX node users. 


SH/WWYV Lists WWV reports (max of 5). 
Lx Send your following lines to a specific user (x). 
Txzzz Senda single line message (zzz) to a specific user 


(x). 
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File Transfer/Manipulation Commands 


Dx 
D y/x 


G 
UP 


Ww 


Wy 


Download a file (x). 
Download a file (x) which is contained in a direc- 


tory (y). 


Initiate file search routine. 


Upload a file. {You must be authorized by the Sysop 
to upload files} 


List what files and/or directories are available for 
downloading files from. 

List what files are available for downloading in a 
specified directory (y). 


MSYS Network Node Commands 
Note: May not be available on all systems/ports. 


BBS 
B 


Connect to Bulletin Board. 
Disconnect from node. 


C# x 


Issue a connect request to a node or station (x). # 
is required when connec ting to a user station to 
identify the port number to be used. 


List avavilable user commands. 
Display basic information about the node. 


Display callsigns of stations recently heard by the 
node. [optional, port #] 


Display KaNodes (i.e.: Kantronics) heard by the 
node. [optional, port #] 


List network nodes heard 

Display description of each port. 
Display routes used to get to nodes. 
Page the System Operator. 


Display list of stations connected to the system and 
their current activity. 


WORLI BBS User Command Summary 


General Commands 


B 
F 


Vv 


Log off the PBBS. 


Displays list of destinations for messages waiting 
to be forwarded. 


Display hardware configuration of PBBS. 


Enter your name (x) in the system. 

Toggle Expert User status. 

Enter your QTH (x). 

Enter your Zip Code (x). 

Enter the callsign (x) of the PBBS where you nor- 
mally receive mail. 


Display PBBS status including what connects ex- 
ist and what they are for. 


Page the System Operator so that you may talk to 
him. 


Display PBBS software version number. 


Message Commands 


CM #x 
E # 


K # 
KM 


L 


LL # 
LU 
L< x 


Send a copy of a message (#) to a station (x). 
Edit message header for a message (#). 


Kill message number #. 
Kill all messages to you that you have read. 


List new messages since the last time you listed 
messages and then logged off the PBBS using the 
B command. 


List oldest # messages. 

List bulletins (ALL OF THEM!!!) 

List bulletin catagories. 

List messages to or from you (List Mine). 

List personal messages. 

List NTS Traffic messages. 

List the last # messages. 

List messages to you which you have not read. 
List message from a station (x). 
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L>x 
L@x 


L# 

L #1 #2 
L”xyz” 
L’xyz’ 


R# 
RH # 


RM 


SBx@y 
SPx@y 


SR # 
ST #@ 


List message to a station (x). 

List messages with a specific coverage area or 
specific PBBS (x). 

List messages numbered geater than or equal to 
#. 

List messages numbered greater than or equal to 
#1 and less than or equal to #2. 

List messages with the specified string (xyz) in title. 
{case insensitive} 

List messages with the specified string (xyz) in title. 
{case insensitive} 

Read message number #. 


Read message number # displaying full message 
header and forwarding info. 


Read all messages to you which you have not al- 
ready read. 


Send a bulletin message to a target audience (x) 
within a specified coverage area (y). 

Send a private message to a station (x) at a spe- 
cific PBBS (y). 

Send a reply to the author of message number #. 


NTSxx Send an NTS Traffic message to the 
specified Zip Code (#) in a specified state (xx). 


Help Commands 


? 
Hx 


H * 


Display a short summary of all PBBS commands. 
Display extended help information for a command 
(x). 

Display COMPLETE Help Documentation. 


File Transfer Commands 
Dyx Download a file (x) which is contained in a directory 


Uyx 
W 


Wy 


(y). 
Upload a file (x) to a directory (y). 


List what directories are available for download- 
ing files from. 

List what files are available for downloading in a 
specified directory (y). 
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B 
DU 


J 


NN 


NH 


AA4RE BBS User Command Summary 


General Commands 


Log off the PBBS. 
Display user status 


List TNC ports - Lists what tnc ports are in use by 
the PBBS you are connected to. 

List Connected - Calls of users that have connected 
lately to the PBBS. 

List Presently Connected - List calls presently 
connected to the PBBS by port “A,B,C....and stream 
brs Blogs 

Calls Heard - Where “p” is the tne port 
identifier.Gives a short list of stations recently heard 
on that port.Typing “JA” will list those stations 
monitored on port A. Typing “JB” will list those 
stations monitored on port B,etc..Use the J com- 
mand to list what ports are active. 


Name - Use as NN yourname to enter or change your 
name in the database. 

Set Home BBS - Use as NH homebbs to enter or 
change your home BBS. 

Toggle Expert mode to enable short prompts and 
messages. 


Zipcode - Us as NZ zipcode to enter your zipcode. 
Talk to Sysop 


Version - Shows version of BBS software 


Message Commands 


Kx Kill msg #x. Also K x x x x to kill multiple mes- 
sages. 

KM Kill Mine - Kills all messages addressed to your 
callsign that have been read. 

KT # Kill Traffic - Kills NTS traffic, even if not addressed 
to you. 

L List any messages that have been posted to the BBS 
since the last time you used the L command. 

LM List Mine - List message to you 

LN List New - list any messages that haven't been read. 

LU List Unread - list messages to you that you haven't 
read. 

LL x List Last x messages. 

Lx List only messages above number x. 

LA List type A bulletins 

LB List type B bulletins 

LT List Traffic 

LF List Forwarded mail 

LY List All messages 

L@ call List AT - List messages addressed to BBS call. 

L> call List all messages sent to call. 

L<call List From - List all messages sent by call. 

LD>x List by Date - List all messages newer than date 
x. Use yymmdd. 

LD<x List by Date - List all messages older than date x. 
Use yymmdd. 

L$ x List BID - Lists messages whose BID is x. 
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LS x List/Search - Lists messages with subjects that 
match pattern x. For information on patterns,Type 
H! at the BBS command prompt. 

Rx Read Message #x. Also R x x x x to read several 
messages. 

RA Read All Type A Bulletins. 

RB Read All Type B Bulletins. 

peal Read All Traffic (NTS). 

RH x Read with Headers. 

RM Read My Messages. 

R$ x Read Bid# - Read messages whose BIDS match x. 

RS x Read Search - Read messages whose subject have 
pattern x 

R> call Read To - Read messages to call. 

R< call Read From - Read message from call. 

R@ call Read At - Read messages addressed to BBS call. 

RD>x Read msgs newer than date x. Use yymmdd. 

RD<x Read msgs older than date x. Use yymmdd. 

REPLY msg# Generate a reply to the originator of msg#. 
Same as SR command. 

SP x @y Send a personal message to x with optional desti- 
nation BBS y. 

SB x @y Send a bulletin to target audience x with specified 
coverage area y. 

SR x Send Reply to message #x. Same as REPLY. 

ST x Send an NTS traffic message to the specified zip 


code x. 


Help Commands 


H 


HL 


I 


Gives a short page of help including info on how 
to get more help. 

Help for Command L- Detailed HELP with indi- 
vidual system commands. For example, type “H 
U” for HELP with uploading. The descriptions in 
this guide are similar to what you would get with 
this command. 

Gives short page of information about the particular 
BBS 


File Commands 


What files - list all of the file direcotrs on the BBS. 
Also shows space remaining. Don't overflow by 
uploading too much! 

What w/Date - List files in specified directory dir 
along with the time stamp. 

What Expanded - List files in specified directory 
dir along with timestamp and size. 

Download file f from directory d. Requests down- 
load of a file. 

Download binary file specifying protocol p, direc- 
torydandfilef. - 

Upload file f to directory d. Upload a file, end with 
AZ or /ex. 

Upload binary file specifying protocol p, directory d 
and file f. 
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Sample BBS Sessions 


cmd:my ka2dew 
MYCALL was KA2DEW 


cmd:¢ potsdm This is a couple of sample BBS operating sessions using a MSYS 
cmd:*** CONNECTED to POTSDM [03/29/91 11:50:25] BBS. In the first session I'm checking in as a new user. In the second 
c bbsjxt session I'll already be registered so I won't have to do it again. 


POTSDM:K2CC-1} Connected to BBSJXI:KA2JXI 

[MSYS-1,11-H$] 

Hello ?, Welcome to KA2JXI's MSYS BBS in Ogdensburg, NY. 

Welcome! As a new user you will see this information. Next time you connect 
you will go directly to the BBS command prompt. Please register as requested 
below. The home bbs you give must NOT be a personal (built into a TNC) BBS 
but rather a well known full service bbs that does mail forwarding. If you 
haven't picked a home bbs yet, you are welcome to use this one. Just enter 
its call with the NH command. 

Please use N command to enter your name 

Please use NQ command to enter your QTH (City and state) 

Please use NZ command to enter your Zip or Postal Code 

Please use NH command to enter call of BBS you want your mail sent to 
Enter command: A,B,C,D,G,H,I,J,K,L,M,N,P,R,S,T,U,V,W,X,?,* > 

n Tadd 

Enter command: A,B,C,D,G,H,I,J,K,L,M,N,P,R,S,T,U,V,W,X,?7,* > 

nq Colton NY 

Enter command: A,B,C,D,G,H,I,J,K,L,M,N,P,R,S,T,U,V,W,X,?,* > 

nz 13625 

Enter command: A,B,C,D,G,H,1I,J,K,L,M,N,P,R,S,T,U,V,W,X,7,* > 

nh ka2jxt 

Entegeconmand: A;B,.G,05G,H,.c. J Kl MEN PR, 55 1,U,VaN, xs %oe > 

ll 4 

MSG # TR SIZE TO FROM @BBS_ DATE TITLE 

2999 B$ 212@ SAREX KD2BD AMSAT 910328 STS-37 SAREX Introduction 

2998 B# 1832 CARF  VE7VCA ALLCAN 910328 INTERNATION CONTEST CALENDAR 
2997 B# 1@15 ALL VE7EMD ALLCAN 910328 Help Find Sin-Cosine Pot 

2978 BS 2127 ALL N2KPK ALLBBS 910327 RE:PK232/TS-440S 

Enter command: A,B,C,D,G,H,I,J,K,L,M,N,P,R,S,1T,U,V,W,X,?,* > 

sp wa2wnt 

Enter title if local, CITY STATE & POSTAL CODE if not local: 

on the air from upstate 

Enter text, end with AZ or /EX, 4A to abort 

Dana, 

It's been a while since I've been on packet. I had to re-register with JXI. 
I'll be home all weekend so perhaps you can connect to my station. I'll leave 
tt on the POTSDM node's frequency. The route is still via PLB, PAN, OGDENB 
though. Good luck on the 145.01 stuff! 


Tadd 
/eX 
Enter command: A,B,C,D,G,H,I,J,K,L,M,N,P,R,S,T,U,V,W,X,?,* > 
b 
KAZDEW de KA2JXI: 73 --- Roger That was an operating session last spring. When I did a 11 4 I was asking the 
*** DISCONNECTED [03/29/91 11:50:25] BBS to list last 4 messages. I could have asked for last 100 although that would 


have taken longer. 


Now here is when I got on earlier this week. This time you'll see that I got 


cmd:¢ potsdm some new mail, read it, deleted it and then disconnected. 


cmd:*** CONNECTED to POTSDM [10/21/91 11:58:03] 
GEDDS Jx1 

POTSDM:K2CC-1} Connected to BBSJXI:KA2JXI 
[MSYS-1.11-H$] 

You have unread mail, please kill when read: 

MSG # TR SIZE TO FROM @BBS_ DATE TITLE 
10501 PN 289 KA2DEW N2CGY --- 911020 Vacation 

Enter command: A,B,C,D,G,H,I,J,K,L,M,N,P,R,S,1,U,V,W,X,?,* > 

r 10501 

MSG # TR SIZE TO FROM @BBS_ DATE Tecnu 

10501 PN 289 KA2DEW N2CGY --- 911020 Vacation 

Tadd, 

We had a wonderful time on the trip and are back safely. Pictures should 
be arriving at your address in a week or so. Drop me a note with when you 
will be back down next time. 

73 from all back home 
*** END OF MSG # 10501 from N2CGY @ WA2PVWV.#ENY.NY.USA.NA 
Enter command: A,B,C,D,G,H,I,J,K,L,M,N,P,R,S,1,U,V,W,X,?,* > 
k 10501 
Msg 10501 Killed 
Enter command: A,B,C,D,G,H,1I,J,K,L,M,N,P,R,S,1,U,V,W,X,?,* > 
b 


KA2DEW de KA2JXI: 73 --- Roger 
*** DISCONNECTED [10/22/91 02:00:29] 
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NAPRA: What’s a node? 


A node is an active location in a 
network. A network is a collection 
of nodes which allow data to be car- 
ried from place to place. Each node 
consists of 1 or more ports. 


For this discussion I'll first break 
down types of ports and then try do 
give a brief description of the differ- 
ent kinds of nodes. 


Ports 

In most cases a port is where a 
radio hooks up to a node. If a node 
has two ports then it usually has two 
radios. Sometimes a node has a port 
that isn't hooked to a radio. The most 
common case is where the node is at 
the same site as another computer 
that is used on packet. The computer 
talks to the node by a wire link in- 
stead of by a radio link. In this case 
there is a port on the node which has 
no radio hooked up to it. The pic- 
tured node would be a four port node: 


In many cases a node is con- 
structed out of a PC. The radios may 
be connected to the PC via TNCs or 
may be connected directly to modem 
cards in the PC such as the case with 
DRSI cards. In these cases there is 
almost always an application run- 
ning on the PC, such as a BBS or 
DxCluster. The application is not 
considered to be a port, even though 
that may be a destination of data. 
The pictured node would then be 
called a 3 port node: 


How a port is seen by a user de- 
pends entirely on the type of software 
used for the node. See Types of Nodes 
for more on user interface. 
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What a radio talks to 

Ports are described by what they 
talk to. What they talk to is described 
as users, servers and nodes. 


Users 

A user is a station which mostly 
accesses information from the net- 
work and sends short packets into 
the network. Personal home stations 
and EOC (Emergency Operations 
Center) stations qualify. User sta- 
tions predominantly connect into the 
network and access information. If 
a user is to send information into the 
network the information is sent 
slowly, as with a keyboard, or infre- 
quently, as with a file or mail mes- 
sage transmission. Very few users 
send more than one file per day into 
the network. Most will send about 
one long packet every minute when 
they are very busy. Personal Mes- 
sage Systems (PMS) usually qualify 
as the PMS usually is sent to by a 
server from the network. The PMS 
doesn't send more than one file per 
day, usually. 


Servers 
A server is a station that of- 
fers a service to more than one 
individual. Servers are con- 


nected to by users and by other 


servers. Some of the servers on 
packet radio today are Bulletin Board 
Systems and Mail Boxes. Both serve 
similar functions as message stores 
and file stores. Users connect to 
these servers and read bulletin 
messages, download information 
files, or send and receive messages 
with friends. Other kinds of servers 
are conference bridges which allow 
many users to communicate in a 
round table, and real time informa- 


tion resources which allow users to — 


participate in the acquisition and 
dispersal of data. One common use 
for this kind of server is Dx spotting. 


Nodes 

A node is a server that is used as 
a real time switch by many users and 
servers. As a real time switch any 
messages that are stored in a node 
are only there for a matter of seconds 
until they can be passed to a desti- 


nation user or server, or to another 
node on the way to the destination. 


Describing Ports 

So, ports can be described as user 
ports, server ports or node ports, or 
a combination of the three. Good 
networking practice has it that ports 
should be configured based on the 
access requirements of the stations 
that it talks to, not on the type of 
stations they are. The ports are di- 
vided into two classifications: Ports 
where stations only receive data from 
the network (user LAN port), and 
ports where stations both send and 
receive data from the network 
(dedicated point to point link port). 
If best network design practices are 
followed, then for any kind of net- 
work node or server, these two port 
types are the only port configurations 
that need to be considered. 


Local Coverage User Port 

A user port is where a user con- 
nects to access the network. Local 
coverage user ports are used exclu- 
sively by stations that are either 
keyboard operated or that are re- 
ceive-only stations, i.e. users. Local 
coverage user ports are on frequen- 
cies chosen to avoid co-channel oc- 
cupancy with servers and other node 
ports. The local coverage user port 
is very efficient in that there are very 
few incidences of collision. The 
reason that this is true is that if all 
users can hear all transmissions 
made by the local coverage user port, 


Even though user A can't hear 
user E they aren't likely to collide 
as they spend most of their time 
listening to LAN port. 
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and users very rarely send data, ex- 
cept as an acknowledgment of data 
transmitted by the local coverage 
user port, then there will be very few 
transmissions that could collide. See 
Hidden Transmitter Syndrome. 


Flat Network Backbone/Trunk 
Port 

There are many ways to make a 
backbone. The most compromising 
way (and the most popular) is to put 
a radio on a frequency and label it 
a backbone. Other nodes and serv- 
ers will have radios on the same 
frequency. In most cases there are 
radios using the frequency that can 
only hear some, and not all, of the 
other radios. This kind of networking 
is called a flat network. The back- 
bone links will perform well only 
when the data throughput required 
is very low. When the data 
throughput on the channel creeps up 
to a value that is somewhere around 
20% of the potential throughput the 
performance on the channel drops 
sharply. Eventually the stations that 
have transmit data will give up due 
to retries or time-outs. This is called 
catastrophic throughput failure. The 
20% figure depends on what stations 
are doing the talking and whether 
they are heard by other stations that 
need to talk but is a good ball-park 
value. One of the worst results of 
catastrophic throughput failure is 
that it is very frustrating to keyboard/ 
real-time users. 


Hidden Transmitter Free 
Backbone/Trunk Port 

A better way of making a backbone 
is to make sure that all of the radios 
on the frequency can hear each other. 
In this case no radio will transmit 
when another radio is already 
transmitting. This provides a per- 
formance increase of better than a 
magnitude over the previous method. 
Most systems that are set up this 
way use a repeater to assure that all 
backbone radios can hear all of the 
other backbone radios on the chan- 
nel. All but one of the sites would 
be a standard transceiver. The one 
site would be the repeater. The major 
flaws in this kind of networking are 
that collisions may result when some 


of the stations are aggressive and key 
up at the same time. Also the 
throughput on the channel is shared 
amongst all of the stations. Ifthe 
backbone is optimized for perfor- 
mance under heavy load it will not 
perform as well under light load 
unless some sort of compensating 
back-off is utilized. This is a feature 
that TheNET does not have, unfor- 
tunately. 


Dedicated Point to Point 
Backbone/Trunk Port 

The best way of making a back- 
bone with standard transceivers is 
to set up dedicated point to point links 
such that each backbone port talks 
to one other backbone port. If only 
two backbone ports are on a fre- 
quency in a given area the Tx/Rx 
cycles of the two nodes will toggle 
gracefully and throughput is maxi- 
mized during any kind of loading 
situation. The backbone port digi- 
tal hardware is optimized for maxi- 
mum transmit and receive response 
based on the other radio being used 
on the frequency. The performance 
increase seen using this approach is 
easily worth the increased invest- 
ment of having a separate port and 
radio for each node to node link, over 
either of the two compromise meth- 
ods discussed in this section. 


Server Multi-access Port 
TCP/IP 

In some networking situations it 
is uneconomical or unfair to desig- 
nate stations which are part time as 
servers and force them to provide 
point to point links. This is the case 
where a station wants to operate as 
a TCP/IP host. A TCP/IP host is not 
likely to be happy on a local access 
user port, forced to be a receive only 
station. TCP/IP is just too powerful 
and neat to be under that kind of 
restriction. On the other hand it is 
rather expensive to have to fund both 
ends of a dedicated link for what 
might very well be a short term toy. 
Many would choose not to toy with 
TCP/IP at all if this was a require- 
ment. Thus the Server Multi-access 
Port. This kind of port is operated 
in a hidden transmitter free fashion 
if it's going to work credibly. It is on 


50MHz, 220MHz, or 420 and above. 
Because of the range limitations that 
are imposed by a simplex HTS free 
LAN builders tend to opt for a re- 
peater environment as described 
above. There are now many TCP/IP 
environments successfully using a 
repeater. One of the TCP/IP stations 
on the LAN is designated to be the 
Network <-> TCP gateway if more 
than a few TCP/IP stations share the 
LAN. Only that gateway station is 
propagated using the TheNET pro- 
tocol. That usually doesn't cause a 
major problem for the TCPers and it 
keeps the node routing tables short 
on the network. On a sparse network 
where there are few nodes in the 
node routing tables all TCPers on the 
repeater would use TheNET protocol 
to talk into the network. 


Wide Coverage General Access 
Port 

In some areas there is so little 
population that local coverage user 
access ports are not justifiable or 
affordable. Also there are areas 
where packet equipment was placed 
on high mountains and hasn't been 
upgraded to local coverage equip- 
ment due to lack of interest, lack of 
financing or because it is just im- 
possible to subdivide the coverage 
because of very rugged terrain. In 
some existing packet systems there 
are systems that are entirely based 
on single frequency 2meter nodes. A 
port that faces such an environment 
but that is part of a node stack such 
as we are describing in the Notebook 
is called a Wide Coverage General 
Access Port. This kind of port should 
be avoided in all new systems and 
should be made redundant as soon 
as possible in existing systems. 


Types of nodes 
Digipeater: 

This is not referred to as a node 
by packeteers although technically 
itis anode. This kind of node accepts 
traffic from a packet station and re- 
lays the traffic to another packet 
station. Only traffic from one station 
to one other may be stored in the 
digipeater at a time. The digipeater 
will ignore other traffic until it can 
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deliver the stored traffic. The digi- 
peater does not acknowledge traffic 
handed to it, rather it is up to the 
destination station to take care of 
this. Thus if the digipeater is unable 
to deliver the traffic (the destination 
station gets QRM or signal too weak) 
it is up to the sending station to re- 
generate the data (retry). 


Single port TheNET, NET/ 
ROM, G8BPQ or MSYS: 

This kind of node will accept a 
connect from a user station and al- 
low the user to request a connect to 
another node or to another user. 
Data from a user is acknowledged by 
the node and then delivered to the 
next node or destination station. If 
the destination station or next node 
doesn’t acknowledge the packet it is 
resent by the node. 


Single port nodes broadcast lists 
of known nodes so that each node 
knows of all of the surrounding 
nodes. Taking advantage of this the 
user can connect to a local node and 
then request a connect to a ‘next node’ 
that may be several nodes away. The 
node will recognize the connect sta- 
tion as another node and will attempt 
the connection via whatever route is 
required to make the path. The path 
is usually selected based on the au- 
tomated nodes broadcasts so some- 
times the single port node may be 
tricked into using a path that is un- 
reliable or might not work at all! 
(Covered in more detail later in this 
document) Most single port nodes 
are individual efforts and no system 
wide design philosophy is used so 
that many if not most paths between 
nodes are unreliable. It is always 
true, however, that a multi-node path 
will require traffic between the nodes. 
This traffic will be on the user’s fre- 
quency, thus causing all of the users 
within range of the multiple nodes 
to be delayed. This also leads to 
tremendous occurrences of hidden 
transmitter syndrome (described 
later). 
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Single port KAnode: 

This node is similar in operation 
to the single port TheNET and NET/ 
ROM nodes except that automatic 
generation of node lists is limited to 
the adjacent nodes. This means that 
any connect to a ‘next node’ will not 
be via any intermediate node. KA- 
node does support automatic use of 
digipeaters between nodes however 
it is not compatible with TheNET, 
G8BPQ etc.. 


Multiple port TheNET, NET/ 
ROM, G8BPQ, MSYS: 

Like the TheNET and NET/ROM 
nodes described above this node al- 
lows the user to connect and then 
request a ‘next node’. An important 
difference is that the ‘next node’ may 
be on a different frequency! These 
nodes consist of 2 or more indepen- 
dent ports, each port being a sepa- 
rate digital section and radio. The 
ports communicate via wires and are 
located at the same site. Connection 
between the ports is usually at 9600 
or 19200 bauds (as compared to the 
usual speed of radio communications 
at 1200 bauds). Thus operation from 
one port to another at the same node 
site is nearly instantaneous. 


Using multiple port nodes it has 
been possible to have packet users 
connect between frequencies trans- 
parently to access other users and 
automated packet stations (like mail- 
boxes and bulletin boards). One idea 
that sprang out of this capability is 
the concept of the backbone. 


Early Backbones 

A backbone was taken to be a fre- 
quency on which two or more nodes 
communicated. This frequency 
would be other than two meters and 
would exclude keyboard users. This 
was so that there would be fewer ‘hid- 
den’ sources of data. It was presumed 
that this would improve the perfor- 
mance of the remaining stations and 
nodes. 


Lack of performance on backbone 
circuits is proportional to the volume 
of data produced by hidden stations 
not the number of hidden stations. 


Backbones: What happened? 

What has happened is that each 
region would set up a backbone 
channel such that long haul traffic 
could be moved off of 2 meters. Some 
of these backbone channels were set 
up by bulletin boards (before 
TheNET and NET/ROM) so that 
traffic could be sent to other BBSs 
without interference from individual 
non-bulletin board stations. A 
popular example of such a backbone 
implementation was the common use 
of 221.11 and 441.0 in the north- 
eastern states. 


Since the advent of multiport 
nodes it has been possible for traf- 
fic to pass from one regional backbone 
to another in a single point to point 
connect. I.E. a station from Con- 
necticut could connect to a station in 
Maine by connecting from his 2 meter 
radio to a node that had 220 capa- 
bility which would talk across 220 to 
a node that had both 220 and 440, 
and then across 440 to a node that 
had both 440 and 2 meters, and then 
back to 2 meters. As time went on 
each of the backbone frequencies (and 
there were only several) has gained 
in quantities of nodes and quantities 
of data. Originally there was no at- 
tempt to control hidden transmitters 
and precious little to control erro- 
neous path generation due to un- 
balanced transmitters verses re- 
ceivers at each site. (Automated node 
broadcasts, remember?). 
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Northwest network node 

A Northwest node consists of all 
of the interconnected TNCs, comput- 
ers, radios and associated hardware 
at the single site, which performs the 
switching functions for it's piece the 
network. The definition holds true 
for whatever type of networking soft- 
ware in use. I.e. NOS, MSYS, 
TheNET, NET/ROM, ROSE, 
TEXNET, G8BPQ etc.. 


These nodes have multiple ports, 
at least one of which is a backbone 
port. The backbone ports talk to 
other backbone ports such that 
packet data can travel from node to 
node on non user frequencies. (This 
way users are the only stations that 
have to share user frequencies) The 
important difference between this 
network node and most other mul- 
tiport nodes is that the backbones in 
the this system are maintained as 
hidden transmitter free point to point 
links (See page on hidden transmit- 
ters later in this package). This is 
done simply by supplying a separate 
set of radios on an independent fre- 
quency for each backbone. In con- 
cept this is extremely simple and 
obvious. This incurs several disad- 
vantages however. 


Northwest node: 
Disadvantages 

The first is obviously cost. Each 
of the sites houses at least 2 sets of 
radios and TNCs, most sites must 
have 3 or more. Most have 4 or more 
sets. That’s a lot of radios and TNCs. 


The second disadvantage is that 
each frequency must be chosen to not 
have interference from any other 
station, at a different site or at the 
same site. It’s difficult to have 2 
backbone frequencies coming into a 
single site on frequencies that are 
near each other. There are really 
only 2 bands on which backbone links 
are conveniently constructed, 220 
and 440. Ifa site has to have 3 or 
more backbones it is important to 
maintain frequencies that are sepa- 
rated when in the same band and 
radios and antennas that will not 
interfere. This becomes a technical 
challenge. Also there should be a 
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different frequency for each backbone 
in a given region. That becomes an 
administrative challenge. In order 
for the system to work well there 
cannot be other stations operating on 
the backbone frequencies. That be- 
comes a public relations challenge. 


Northwest node: Advantages 

So, why bother? The first answer 
is performance! There is at least a 
5 times performance increase using 
the same baud rates and hardware 
as a flat network. If only two stations 
are talking to each other across the 
backbone the timing values in a 
TheNET or equivalent node may be 
maximized for that situation. That 
can lead to a 20 times performance 
increase, or more, over a non hidden 
transmitter free backbone. That’s a 
20 times improvement (at least!) with 
a 1.5 times increase in site cost. Not 
too bad a trade off. 


The second answer is market- 
ability. Once built in the way de- 
scribed in this document a network 
is usable by keyboarders, Dx spotting 
networks, BBS stations for for- 
warding, users for access to BBSs, 
TCP/IP hosts, etc. Because network 
site to network site transport is 
moved off of 2 meters that band may 
be used for low power personal key- 
board stations. The amount of fun 
and interested had by all of the 
network users and participants goes 
way up. A 60% of all hams involve- 
ment rate is achievable. This will 
allow a very successful packet pro- 
gram to exist. 


The third answer is adaptability. 
It is easy to replace or reconfigure all 
of the ports on a single backbone 
channel with many fewer complica- 
tions because there are only a few 
sets of equipment involved. A per- 
formance increase on all ports in- 
volved could be achieved by adding 
4800 baud modems at each of the few 
sites. 


It’s not really that hard to add 
additional ports to a single or dual 
port node. For example at sites with 
limited antenna space it may be pos- 
sible to use dual band and diplexed 
antenna systems to achieve multi- 


band operation. Most backbone links 
run relatively low power and direc- 
tional antennas which make it easy 
to keep the transmitters out of the 
receivers. 


Backbones using repeaters 
Instead of supplying separate sets 
of hardware for several backbone 
channels at a site it is possible to do 
backbone linking through a repeater. 
The repeater would be placed at one 
site and then several others would 
access it. There are several advan- 
tages and disadvantages to this. 


Repeaters: Disadvantages 

¢ Each site that links to the re- 
peater must have a dedicated radio 
on the same frequency pair as the re- 
peater. This ties up two frequencies 
and the same pair must be used at 
each site. This is instead of being 
able to choose a different link fre- 
quency from the ‘main’ site (that 
would have the repeater) to the other 
sites based on the spectrum availabil- 
ity at each of the sites. 


¢ The total data throughput 
(added for all site‘rptr links) is go- 
ing to be less than the baud rate 
(which must be the same on all links 
to that repeater). Ifthe N links were 
on independent frequencies the 
throughput is theoretically N times 
the baud rate for a system of N sites. 
This is because a different set of data 
can be traveling on each of the links 
at one time instead of only one set 
of data as in the case of the repeater. 


¢ Collisions can occur between sta- 
tions accessing the repeater if they 
both key up at the same time. 


¢ One station on the repeater can 
set his timing values such that the 
one station exceeds the theoretical 
throughput for the average station. 
This will improve that station's tim- 
ing but drastically reduce the total 
throughput. 

¢ The repeater turn-on time is 
added to TXDelay for the remote sta- 
tions in many repeater arrange- 
ments. 

e If the repeater should fail all 
sites that depend on it loose connec- 
tivity. 
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¢ Throughput on a repeater is only 
going to be good enough for a back- 
bone between expandable node sites 
if the repeater channel baud rate is 
much higher than the baud rate 
needed on point to point links. High 
baud rate repeaters are much more 
difficult to build and maintain than 
low baud rate point to point links. 


Repeaters: Advantages 

¢ The total packet travel time on 
the repeater, if not overloaded, would 
be half that of a separate link sys- 
tem. 


¢ The cost of the system is one full 
duplex radio and 1 normal radio per 
site as opposed to 2 radios times 
number of sites. 


¢ Ifa central link site is necessary 
and that site is a commercial radio 
installation it might not be practical 
to have several link radios. A re- 
peater only needs one antenna. 


Note on repeater usage: All sta- 
tions involved in the repeater op- 
eration must be using modem tone 
DCD, not noise level DCD unless the 
repeater has a very short keyup and 
unkey delay. - 


Repeaters should be used on user 
ports or for tying part time or low 
usage servers into the network where 
the servers aren't feeding other 
servers. In other words, if a server 
has only one port then it could be 
tying into the network via a repeater. 
If a server has two ports then it 
should be using a point to point link 
to get into the network. For user 
access to the network repeaters are 
excellent but only if the repeater is 
exclusively for low duty cycle users. 
Users sharing a repeater with a 
server is not a good idea. 


What does it take to make 
a Northwest node? 


The most common node configu- 
ration consists of: 


two UHF or 220 FM radios, 

a 2 meter radio, 

two yagis, 

an omni, 

three TNCs, 

three runs of coax, 

a power supply, 

a HexiPus™ or other diode 

matrix. 

¢ three ROM chips with 
TheNET, 

¢ miscellaneous serial cables, 
mike cables and power cables. 

The omni is 6dB gain or less for 

the 2 meter user port. Depending 

on the population density in your 

area your user port may be very low 

power, even to the point of having 

attenuators in the receive path. 


User Port Recommendations 
Most sites have a user access sim- 
plex 2 meter user port. The user port 
is geared to cover about 50 pack- 
eteers. If the normal ratio of hams 
to non hams is 1:600 and the normal 
ratio of packeteers to hams is 1:2 then 
the population area that your user 
port should cover should be less than 
60,000. If there are 5 frequencies 
available on 2 meters then a city of 
300,000 could be covered with very 
little concern for over-coverage. Be 
sure to take rural areas into account 


when calculating coverage. It is 
important that the number of pack- 
eteers (stations that receive-mostly) 
that must use a single user port is 
50 or less. If more than 50 need to 
access the user port then attrition of 
packeteers will result. Thus it is 
important to watch for over coverage. 
It is also important that some fre- 
quencies are left available for expan- 
sion and experimental operation. It 
would be real silly of us to assume 
that we're using the best possible 
networking tools. Some frequencies 
must be left on 2 meters for high tech 
LANs. It should be stressed that 
‘high tech LAN’ does not include a 
wide area coverage mess. 


If a situation exists where there 
are more than f* 60,000 population 
a directional antenna might be used, 
or attenuators for reduced range. 
Also keep in mind that the more 
LANs in the area, the better. If some- 
one wants to put up a node where 
there is already LAN coverage then 
space must be made, by dividing cov- 
erage with the aforementioned direc- 
tional antennas. Telling someone to 
not put up hardware when they of- 
fer is as good as telling the FCC that 
we don't need an amateur service 
after all. The thing to do is to tell the 
newcomer how to use the hardware, 
not whether to. Think up some good 
way to use the equipment without 
compromising the network and with- 
out hurting the other users. Show 
them this book. Get it together! 


Backbone Recommendations 
Each site has at least one hidden 
transmitter free backbone port that 
talks to another node. The backbone 
port is on 50MHz, or 220MHz and 
above. Most of the backbone ports 
use yagi antennas pointed at the 
neighbor node to which the backbone 
runs. This way we have some hope 
of reusing backbone frequencies 
within the network. It is also de- 
sirable for practical and financial 
reasons to put more into the antenna 
so that sensitivity and output power 
may be minimized. The backbone 
port must be running software that 
is protected against unauthorized op- 
eration. The software we've been us- 
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ing mostly in the network is TheNET 
Plus v2.10st by Bill Beech and 
TheNET X1 by G8KBB. The param- 
eters used in a backbone node are op- 
timized for each end of the link. This 
allows us to often have less than 
300ms transmit/receive overhead on 
a backbone link. 


The most successful nodes have all 
ports based on TheNET software 
running in a PAC COM Tiny 2, MFJ- 
1270B or other TAPR2 compatible 
TNC. It is quite possible that in the 
future nodes will be based wholly on 
other kinds of equipment. 


Networking Resources 
NEDA now sells a HexiPus™ di- 
ode matrix board for $29.95. There 
is an order form at the end of this 
document. 


Recent vintage TNCs may be tied 
together at 9600 or 19.2K baud (only 
the PAC-COM will do 19.2K baud) 
across the matrix. The matrix is un- 
necessary for a 2 port node. 


So, to make a 3 port node (user 
port and 2 backbone ports) you'll 
need the following: 


2m rig, gain omni antenna, coax. 


440 backbone rig, end mount 
beam or dipole, coax 


220 backbone rig, end mount 
beam or dipole, coax 


3 TNCs, 3 node chips, 


HexiPus™, cable hardware (con- 
nectors included with PAC-COM 
TNCs) 


Power supply and control point 
mechanism. 


Other Comments 

Node sites don’t necessarily need 
to be located on a big hill. It is im- 
portant that it can serve a specific 
geographic region of users with its 
coverage effectively and not interfere 
with adjacent packet systems using 
the same frequency. Some systems 
that are at high elevations tend to 
“hog” a given user channel over a 
larger territory than necessary. A 
better approach is to create small 
local area networks (LAN) with well 
defined areas of coverage. This also 
allows for the reuse of 2 meter user 
channels at nodes that are closer 
together without interference. Fur- 
ther efficiency is achieved by the fact 


that fewer users will access each user 
port. This is called the cellular ap- 
proach to user ports. 


Node site accessibility is also an 
important consideration for con- 
structing a node. There are some se- 
rious advantages to putting nodes at 
the node owner’s house: 


¢ Thenode can be serviced in short 
notice and with little hassle. 


¢ The operator can observe prob- 
lems that might not be apparent 
from a remote station. 


¢ Radio equipment that is not hard- 
ened for an outdoor environment 
will work fine at a home node lo- 
cation. 


e The site manager may attach 
other systems to the node via a 
wire link (as opposed to radio link) 
such as a BBS, TCP/IP station 
etc. 


e¢ Diagnostics may be done to the 
station using equipment that one 
might not want to haul or leave 
at a mountain site. 

¢ Node reconfiguration for experi- 
mental or emergency linking is 
possible. 

¢ Christmas lights are unnecessary 
as the TNC light show is fantas- 
tic 

¢ Thenodeis available for demo for 
curious visitors. 
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Now that you've heard what the 
nodes look like here's what led to this 
design. 


Important Considerations when 
first specifying network hardware 
and direction included: 


¢ Network capacity; 

Can the network handle the capac- 
ity that will be imposed on it? This 
is partly determined by the existing 
network as the users will generally 
only expect what they have already 
gotten used to. 


Network Concept 


¢ Network promotability; 
A good network is of little use if the 
target audience can't understand it. 


e Operator and technician avail- 
ability to fit the chosen hardware 
and software; ; 

Using equipment or software that is 

obtained or built only with special 

talents or connections to build the 

prototype network will not lend to a 

successful network, So, either choose 

off-the-shelf components or start your 
network development by creating 
sources for the required materials. 


¢ Politics; 

Unfortunately this is an important 
consideration. In order for your 
budding network to survive it must 
allow for the participation by people 
who are greedy and egotistical. The 
network design must allow avenues 
for those people to help the network, 
without destroying it. In the same 
token it’s important that no design 
rules are made which give special 
privilege, especially where this may 
be construed to be negative by any 
party. 


Basic Networking Guidelines For An Amateur Radio Packet Network 


If these rules are followed the 
participants will create a fun, ex- 
pandable and upgradable packet 
network that will be the equal of any 
in the world. Compromising on these 
in any way will lead to limitations 
and eventual dead ends. These rules 
apply to amateur radio in the United 
States and may see some modifica- 
tion in other countries merely due to 
spectrum changes and government 
regulations. If a system is going to 
be created and used by hams, and 
depend entirely on ham radio, then 
these are good rules: 


1. All backbones are dedicated 
point to point links. Backbones 
are on 50MHz, 220MHz and up. 
Backbones are never on 
144MHz. See Hidden Trans- 
mitter Syndrome. 


2. LANs have only a network con- 
nect. Just one node for access 
to the network and no more 
than 10 active users at a time 
during a standard operating 
period. Users connect to the 
node and then away from the 
node, either via the network or 
direct from the node to another 
users. No digipeating. 


3. Servers connect to the network 
via dedicated links if they are 
high volume data generators or 
via hidden transmitter free 
shared links if they are not high 
volume data generators. Server 
links are on 50MHz, 220MHz 
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and up. Server links are never 
on 144MHz 


4. User access to servers is via the 
network. Servers shouldn't 
have any 2m hardware as they 
are connected to via the net- 
work. An exception is where 
users can gain network access 
via the server in which case: the 
server would be also be consid- 
ered a user access port; the 
server frequency is not on the 
same frequency as any other 
user access port; users can get 
to the rest of the network from 
the server's user port. In any 
case servers don't need 2m 
hardware on the same fre- 
quency as another user access 
port within RF range. (Except 
for redundancy in which case 
the redundant radio is normally 
disabled) 


5. Corollary of 2. Local coverage 
user LANs are designed so that 
they do not see other nodes or 
users of other LANs. LANs 
need to be low power so that this 


can work. No node to node — 


communications may exist on 2 
meters. See Hidden Transmit- 
ter Syndrome. 


6. Locations and mechanical de- 
sign of node housings are not 
important. Nodes may be on 
mountains or in homes. Back- 
bone and dedicated links may 
be of high or low power depend- 
ing on need. 


7. Length of backbone hops is not 
important. Reliability and sig- 
nal to noise ratio are important. 


8. All nodes/users in the network 
must have standardized win- 
dow sizes. They don't have to 
be the same but they must be 
agreed upon by all network level 
4 data sources. This is impor- 
tant because otherwise network 
users will not have the same 
priority. 

9. Any station that will transmit 
data at greater than 300 chars/ 
minute is a server. Any station 
that provides services to sta- 
tions over the radio is a server. 


10. Link and backbone throughput 
should be improved as loading 
increases. 1200 baud is pretty 
good for backbones in a new 
network, if links are point to 
point, dedicated, and with no 
interference. See Node Radio 
Considerations. 


11. Radio interference from on site 
equipment is just as bad as in- 
terference from off site equip- 
ment. It must not be tolerated. 

12. Redundancy is important. 

These are good rules for any amateur 
radio packet network using AX.25 based 
link layer protocols. Additional 
restrictions may be imposed by network 
software. Any comments on these rules 
should definitely be aired. Times and 
technology change. This is a good start 
though. 
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Any new network expansion 


should use 1200 baud point to point 
links for the following reasons: 


1200 baud is misconstrued as be- 
ing slow, especially by those who 
are only used to non-point to point 
links. A 1200 baud point to point 
backbone with 250ms keyup de- 
lays can pass 8 Megabytes per 
day. 

Any network linking equipment 
that is installed and working is 
worth substantially more than 
just the parts. That means that 


Use 1200 baud first! 


you can turn around and reuse 
the equipment somewhere else if 
you upgrade an existing link. 
Waiting to get faster equipment 
before putting in a link is silly. 
Put it in slow, first, rather than 
wait. Then upgrade as resources 
become available. A 1200 baud 
point to point link is far better 
than a HTS infested link channel. 


If you have a network that is pro- 
moted to all hams, you will find 
that some of them will desire to 
get involved and expand your 
network. This will lead to more 


network facilities and redun- 
dancy. The more people building 
on the network the better it will 
be for all. 


1200 baud equipment is easy to 
work with. Once your system is 
up and running it is trivial to 
promote others in your area and 
in adjacent areas to add on to the 
system. 


Higher baud rates are not as good 
as they may seem because factors 
like TxDelay are not changed just 
because you up the baud rate. 
They just become more obvious. 


TheNET Network Development Guidelines 


Time-to-live should be estab- 
lished network wide. Link 
qualities should be set so that 
the furthest propagating node is 
not as far as time-to-live. See 
Node Propagation. 


Windowsize parameters should 
be the same and should be a low 
number. The value should be 
such that during 50% loading 
the number of packets out- 
standing for a given connect is 


about 1 per 10 seconds of 


planned latency. This allows for 
approximately 23 characters per 
second through put for each 
connect. With 100cps through- 
put rate on backbones and a 
time-to-live such that three 1200 
baud backbones are the maxi- 
mum traversed in a L4 hop a 
windowsize of 2 is appropriate. 


Nodes broadcasts should be 
turned off on local coverage user 
ports to discourage node to node 
communications on 2 meters. 
This makes it so that a node on 
your local coverage user fre- 
quency won’t see a nodes broad- 
cast from your node. The users 


will be able to get nodes lists etc.. 
Nodes propagation in and out of 
the node via the RS-232 port still 
works. This makes it so that if 
somebody decides that they 
want to put up a node and link 
into the network by your LAN 
port that they are discouraged 
from doing this, immediately. 
Nothing is so frustrating as to 
be informed of a rule only after 
breaking it. By setting up the 
node in this manner a potential 
abuse is stopped before it begins. 


# node propagation needs to be 
turned off. This is because of the 
limits on node list length. This 
also reduces the length of node 
list broadcasts. 


Retry rate/level 4 time-out 
should be the same for all nodes 
and should be greater than the 
worse time it takes to transmit 
the maximum length message 
the maximum number of nodes 
allowed by time-to-live and over 
the worst path in the network. 


6. 


Nodes whose L4 retry rate, L4 
windowsize and time-to-live are 
not predictable must not be al- 
lowed to take part in network 
level 4 operation. All L4 network 
hardware operators must agree 
on these figures. This makes 
sure that all network users get 
as close to an equal share of the 
network capacity as possible. 


Level 4 operation means that the 
node can pass data to another node, 
multiple hops away. Ifa station is 
denied level 4 access then it must do 
asimple connect to the adjacent node 
and then connect on intothenetwork. 
This might be necessary in the case 
of anon-compliant TheNET, MSYS, 
NOS, G8BPQ 


{6 


Nodes broadcast limitation and 
nodes broadcast reception con- 
trol are used to limit the level 4 
access of nodes that are not net- 
work participants (i.e. who don't 
abide by the above rules, in- 
cluding rule 6). 
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How To Use The Network 


Let us take as an example a new user. The user wants to get to a friend 
in Poughkeepsie New York whose call is K2QRM. Our user is located in 
Exeter NH. Assume for the sake of the example, that both are using 2 meter 
stations and have base station antennas. The station in Exeter is looking 
at his NEDA user port map and finds that KNGSTN:WB1DSW-5 is on 
145.05. He dials his radio over to that frequency. Next he tells his TNC 
to connect to WB1DSW-5. He gets a message on his display that says: 
*** Connected to WB1DSW-5 

At this time, out of curiosity he asks the node for its INFO message and 
a list of nodes by doing the following: 


if 

KNGSTN : WB1DSW-5} 

sysop WB1DSW & NRIN 
QTH East Kingston NH 
freq 145.05 

info NR1IN@WB1DSW 


download file NETWORK in the N directory 
( DN NETWORK ) on WB1DSW BBS for more information about local nodes 
then he types: 
N 
KNGSTN: WB1DSW-5} Nodes 
ARLNG1:K1CF-1 ARLNG2 :K1iCF-2 
BBSASH : KB4N BBSDSW:WB1DsSW-5 
BBSN:NS1N BBSPHY:WA1PHY-1 
BELNAP :N1DCT-3 BERK: WA1TPP-3 
BERK4:WA1TPP-9 CENTNH : K1BKE 
DENNIS :KQ1K-7 NASHUA: KA1G0Z-9 
NHOEM3 :WA1WOK-3 NSHORE:KC1PK-5 
SCIT:NS1N-5 SWNH : KA1LBBG-1 
WNDHM1 : KiTR-1 WNDHM2 :K1TR-2 


ARLNG4 :K1CF-4 
BBSEDY : KA1LEDY-1 
BBSWOK : WA1LWOK-2 
BERK2 : WALTPP-13 
CHSTR: K1MEA-2 
NBY: KALEDY-5 
NSHR22 :KC1PK-3 
STMFRD:KB2CS-1 
VNH: WALTLN-1 


ASH: KB4N-5 
BBSGOZ:KA1GO0Z-1 
BED: WA1PHY-3 
BERK3 :WA1TPP-14 
CROWD: WA1WOK-7 
NHOEM1 : WA1WOK-1 
SALT: KQ1K 
SWNHU : KA1BBG-4 
YCCCDX:K1TR-3 


The Info message can be up to 160 characters long and is set by the node 
manager. All of the N.E.D.A. nodes have useful info messages. The nodes 
list is a table of node names and callsigns of the nodes that are available 
via the backbone within 3 hops and in some cases the nodes that are heard 
by the user port on the user port frequency. Referring to the map our user 
sees that CLV:N2CJ-1 is a node near Poughkeepsie NY. The route from 
KNGSTN to CLV is KNGSTN -> WNDHM -> CHSTR -> STMFRD -> 
KNDRHK -> CLV. Each step is via HTS free backbone links. Because 
the system only shows nodes three hops away the user must step to a mid- 
point node. STMFRD shows in KNGSTN's nodes list. He then types: 

C STMFRD 

if all goes well about 15 seconds later he gets the message 
KNGSTN:WB1DSW-5} Connected to STMFRD:KB2CS-1 

C Ci, 

and after 30 seconds gets the message 

STMFRD:KB2CS-1} Connected to CLV:N2CJ-1 

At this point our user can type 

C K2ORM 
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and after about 35 seconds gets 
CLV:N2CJ-1} Connected to K2QRM 


Now any text typed by our user 
will go to K2QRM and any text from 
K2QRM will come back to our user. 
To terminate, either party simply 
exits back to command mode using 
control C and types D as usual. 


If our user desires he may connect 
back to KNGSTN node and then to 
STMFRD and type an N command. 
This will show the nodes that 
STMFRD knows about from it's point 
in the network. Note that the user 
ports on KNGSTN and CLV (as well 
as STMFRD) may be on different 
frequencies. It is only important that 
the frequency of the user port is the 
same as the users that is talking to 
it. The network is responsible for 
connecting user port to user port. In 
this case KNGSTN is on 145.05 and 
CLV is on 145.09. Even if they were 
both on 145.05 the network would 
still be used to pass the traffic. Also 
in this case KNGSTN and CLV are 
about 200 miles apart. At each hop 
the data travels from node to node 
via the backbones. Each backbone 
is on a separate frequency. All of this 
is transparent to the user. 


When you establish a frequency for 
your station you should make note 
what network user port serves your 
station best. You can then tell your 
friends how to get to you from the 
network. 


This document's purpose is to 
provide the information necessary to 
build a network of this type. Also 
included is more information on us- 
ing the network, both as a user and 
as a server. 

Happy Packeting! 
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Hidden Transmitter Syndrome 


This is the bane of most earlier packet networks. A 
system with 3 sites: Station A and Station C are far 
enough apart that they don’t hear each other at all. 
Station A has traffic to go to station C and station C has 
traffic to go to A or B. Station A will transmit when it 
doesn’t hear anything. Station C will do the same. Site 
B hears both A and C. If C is transmitting and A de- 
cides to transmit, both messages are lost. If A is wait- 
ing for a reply from B and C is talking, then A has to 
wait. If C is talking for too long, A will retry, thus 
trashing the message C is sending to B. 


If the A to B link was on a different frequency than 
the B to C link, the observed performance increase is 
greater than 5 times, regardless of the baud rate! A 
hidden transmitter is a station that can be heard by one 
or more stations on a frequency but can not hear ALL 
of the stations on the frequency. It is the stern recom- 
mendation of NAPRA to not allow hidden transmitters 
on backbones. 


Hidden Transmitters on User Ports 

Clearly it is not possible to eliminate HTS on simplex 
user ports. It is certainly possible to eliminate HTS on 
a user port if the user port could take advantage of a 
duplex repeater. However, given that most user ports 
are simplex systems the effects of the hidden transmitter 
problem must be taken into account 


If the user port node is the only station on frequency 
that can hear everybody and if all stations on frequency 
have parameters set to take advantage of this, the fol- 
lowing is true: 


Given that a user port can be heard by all stations 
on a LAN: Time used for data transmission by the node 
is about 80% efficient. Time used for data transmission 
by user stations is about 80% efficient, under minimum 
load. Under maximum load the time used for data 
transmission by the node is still 80% efficient but time 
used by the user stations drops down to near 0% efficient. 
Thus it is useful to have sources of lots of data (i.e. au- 
tomated stations like BBSs) to be sourced through the 
network and not from a normal user site on a 2 meter 
user frequency. 


Site B 


Station A 
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For this reason NAPRA requests that stations which 
source a lot of data (i.e. servers, hosts and BBSs) use 
dedicated link channels on 50, 220, 440 or above. This 
allows for the best of all worlds for the servers and for 
the users. If we create our network in this fashion we'll 
create a system which will grow and in which fun and 
learning are maximized. 

Minimizing HTS 
1. On Backbones: 

Keep each link hidden transmitter free. Try to con- 
figure backbones as dedicated end to end links using only 
two radios per frequency/link if on a high traffic path. 
High volume means that there is channel activity as 
much as 1/4 of the time during peak loading periods. 


Set persistence values at each port on a backbone to 
256/(N-1) where N is the number of nodes on your 
backbone frequency. Example: If 4 nodes on backbone 
frequency then use Persistence of 85 at each port. 


Set slot time at each port on a given backbone equal 
to TXDelay for that port. 


2. Users that are high data volume sources: 

- High data volume sources should minimize collisions 
with low volume users by setting up dedicated uplink 
channels to one or more local nodes. Arrangements might 
be made with other local high data volume sources to 
share a dedicated link port. This should not be on 2 
meters. 


3. Users that are not high data volume sources: 

These users should arrange to use minimum power 
to assure full quieting signal at a NAPRA node user port 
which has few or no co-channel nodes or servers. Ob- 
serve the node in monitor mode and see what/who is 
uplinking to it. What/who is downloading is much less 
important. On channel DXing of user ports is seriously 
not a good thing. 


Keep MAXframe low (1 or 2), and DWait at 16. 
CROWD conference nodes let you use PACLEN up to 
240 so set it at 240. 


. Station C 
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TCP/IP and Packet Networking 


TCP/IP is one of the protocols that run 
across the TheNET network. The way 
this works is that TCP/IP hosts have 
dedicated links into TheNET node sites 
on 220, 440 or up. Then the TCP/IP host 
transmits a TheNET node ident into the 
network. The Idents all start with the 
two characters ‘IP’. Thus IPWMA, 
IPQRP etc.. That node ident propagates 
up to 7 TheNETs away to all other 
similarly linked TCP/IP hosts. TCPers 
that want to access hosts across the 
network must route through TCP/IP 
hosts along the way. No end to end 
TCPing is supported as the node 
broadcast qualities in the TheNET 
network are only 7 hops. For new TCP 
systems where this would be a problem, 
compromises, either involving software 
hacks or additional appropriately 
located TCP hosts may be constructed. 
Check the user port maps for the 
locations of TCP hosts in the network. 
Check in the Dedicated Link for your 
local TCP/IP address assignment 
coordinator. 


Transmission Control Protocol/ 
Internet Protocol. TCP/IP defines a 
protocol suite. TCP/IP is a system of 
messages sent between computers, via 
radio (or telephone, or wire) that enable 
the computers to exchange data 
meaningfully. Where AX.25is a protocol 
that defines how two TNCs can 
communicate, either directly or via 
digipeaters, TCP/IP is a protocol suite 
that defines how two computers can 
communicate, over wire line, telephone 
with modems, two or more TNCs, NET/ 
ROM, TheNET, ROSE, etc. TCP/IP is 
called a suite of protocols because it 
actually includes hundreds of different 
message types and response procedures 
for dozens of different purposes. 

Defined in TCP/IP as commands (and 
separate protocols) there are TELNET, 
FTP, SMTP, FINGER, PING and others 
that are of direct use to the user. 

TELNET establishes a real time two 
way interactive connection between a 
user at his own computer and another 
remote computer. This lets the user 
command the remote machine as if he 
were sitting at the keyboard of the 
remote machine. Thisis similar in effect 
to how an AX.25 user perceives TheNET 
and BBS operation. 
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Some TCP stations access the 
network via TCP-only links into hosts 
which are already linked into the 
TheNET network. Additionally it is 
possible for non-TCP stations to access 
TCP hardware over the TCP-only 
network by doing TheNET connects into 
the TCP hosts that are listed in the 
nodes lists. If you use this method, after 
you connect to the TCP host, hit an extra 
carriage return. Then the TCP host will 
respond with a promt. 

The recommended network subnet for 
TCP/IP usage is that one or more TCP/ 
IP hosts would have point to point links 
into TheNET nodes that are in the 
network. Those TCP/IP hosts would 
support a TCP/IP-only repeater. What 
this does is set up a subnet for TCPers 
which would be entirely TCP/IP. That 
allows the TCP stations to use backoff 
and P-persist without competing with 
AX.25 non-TCP stations. Additionally 
it allows the community of TCP stations 
to interact so as to further build packet 


What is TCP/IP? 


FTP or File Transfer Protocol is a 
customized command set for getting or 
putting files on a remote computer from 
the user's computer. Files may contain 
non-text information. This is a key 
feature of TCP/IP for amateur packet 
radio. 

SMTP or Simple Mail Transfer 
Protocol is a system for automatically 
routing multi-line messages from one 
computer to another over any number 
of intermediate computers. Unlike FTP 
and TELNET which require that an end 
to end path must be established in real 
time SMTP allows messages to traverse 
the computers that are available and 
then wait for computers that are 
unavailable and then proceed when they 
come on line. 

FINGER is a command whereby a 
user can ask a remote machine for 
information about another user. Thus I 
could do a finger on the user NQIC on 
the machine NQIC and get back that 
NQIC is Bob Lafleur and whatever 
other information that Bob wants his 
finger file to contain. 

PINGis command to send a packet to 
a remote computer to find out if it is 
connected to the network and if so how 
long it takes to get a packet there and 
back. 


activity. We should stress that 
backbones should be a cooperative 
venture between all packet users. It is 
probably true that there are other 
schemes which would work better on the 
long haul than TheNET. However, 
TheNET is the only protocol currently 
available that supports all kinds of 
packet users. Ifthere isnew information 
on this please present it to the editor. 
Note to computer hackers: UHF link 
radios need not be expensive. All you 
need to do is find a RF hacker to help if 
you don't want to mess with it. There 
have been two separate UHF radio 
notices in the NEDA Quarterly for under 
$80 per rig. (published in this Notebook) 
NX2P Electronics also sells a UHF link 
radio (from PacComm) that would do 
very well. It's in the $200 price class 
per nig. 
—End of File 


There are many other useful protocols 
built into TCP/IP that allow such things 
as data sharing between programs 
running on two different computers, 
identifying what hosts are available, 
finding out the time at a remote 
machine, authenticating passwords and 
even passing silly quotes. 

Message routing with TCP/IP is based 
on a 82 bit address and aliasing. Each 
host computer is given it's own specific 
32 bit network address and a text alias. 
The text alias for amateur TCP/IP is 
usually callsign.ampr.org. The 
.ampr.org is used to differentiate the 
amateur network with the commercial 
networks in cases where there are tie 
ins between the two. The 32 bit address 
if of the form 255.255.255.255 where 
each of the numbers is called an octet 
signifying that it uses 8 bits. Each of 
the four octets from left to right 
decreases in priority. The first octet is 
used to determine whether the 
destination address is ham, military, 
commercial, educational, etc.. The 
second octet might indicated which state 
the destination machineisin. The third, 
depending on how the ham TCP/IP 
addressing committee decides to run 
things, might determine a network node 
output or a county or city. The last octet 
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determines which individual machine 
that the message goes to. So, given that 
the network extends across the country, 
it should be possible to address a 
message from any TCP computer to any 
other. The addressing system also 
allows for more than one user at each 
machine. Piueee lL ecane (be 
ka2dew@kltr.ampr.org which is 
different than k1tr@k1tr.ampr.org. 

The process in the TCP program 
which sends messages from the host and 
waits for acknowledgment from the 
destination station is more sophisticated 
than TheNET. With TheNET up to four 
messages are sent out of the originating 
node and then when acknowledgments 
come back for those messages new 
messages can be sent out again. Four 
messages may be outstanding at a given 
time. If an acknowledgment for a 
message doesn't come back for 5 minutes 
the originating node will regenerate the 
message. With TCP/IP what is a 5 
minute timer in TheNET is 
automatically adjusted depending on 
previous performance of the link. This 
is called ‘backoff. TCP/IP is loaded with 
this kind of intelligent networking 
features. 

TCP/IP using the KA9Q software 
package is very easy to modify. 
NET.EXE which is the original KA9Q 
package has been added to by dozens of 
other amateurs. NOS, Network 
Operating System, is updated and 
customized by many hams for many 
purposes and is entirely public domain. 
This is in contrast to TheNET which is 
only modifiable with great difficulty. 

TCP/IP is a mature protocol system 
due to the vast number of people 
working with it. TCP software is 
available for most computers. It can be 
run over a huge number of different 
kinds of data links. It is extremely 
powerful. It is in use on many, if not 
most, commercial workstation systems 
in the world. Sun Microsystems, Apollo, 
HP, Xerox, DEC, Apple, Next, Wang, 
and most other computer companies 
either use TCP/IP exclusively or at least 
offer support for it as a standard feature 
of their computers. 

For more good info on TCP/IP I 
recommend Internetworking with TCP / 
IP by Douglas Comer and published by 
Prentice Hall. 

Why Aren't All Packeteers 
Using It? 

The first reason is that it won't run in 
a simple TNC. It is quite possible to 
have lots of fun and take advantage of 
many of packet radio's capabilities 


without TCP/IP. Truly there are things 
that we can do with TCP/IP that we can't 
do without TCP/IP. Many things we're 
already doing without TCP/IP could be 
done better with TCP/IP. That won't 
convince all packeteers to use TCP/IP 
from their homes. At this time TCP/IP 
still requires a computer somewhat 
more powerful than a TNC. 

NAPRA requests that TCP/IP hosts 
using the network access it via dedicated 
point to point links or via an HTS free 
LAN. TCP/IP access via 2 meter user 
ports is bad. They must also use 
parameters that are no more aggressive 
that those recommended for the 
TheNET nodes. The reason is that TCP 
stations are themselves networking 
hosts. They can source high volumes of 
data to the network at will and can be 
remotely controlled from other TCP 
stations to do this. In order to function 
across the network TCP switches, by 
there very nature, must be independent 
of the controls that TheNET places on 
network traffic through the TheNET 
parameter controls. Specifically, retry 
rate and window size are controlled for 
NAPRA AX.25 users but couldn't be 
controlled for TCP/IP users. In addition 
the NAPRA network user access policy 
is designed to permit equal access to 
network services by all stations. 
Because of the way packet works in 
regards to hidden transmitter 
syndrome, stations transmitting into a 
user port cause much more loading than 
stations receiving from a user port so 
having TCP/IP stations on shared 2m 
channels would not be fair. This makes 
a TCP/IP station cost about $800 (in 
radios and TNCs) in addition to the cost 
of a PC, instead of about $400 and the 
cost of a dumb terminal for normal 
packet. 

NOS - Network Operating 
System 

NOS is a software package created in 
the past several years whichimplements 
TCP/IP in an amateur radio 
environment. It runs on a PC, Amiga, 
Macintosh and several different 
business computers. An intriguing 
capability of NOS is the ability for a 
TNC-only user to connect into the NOS 
node and then use it's TCP features. 
This opens up the possibility of building 
a network using NOS nodes instead of 
TheNET. Users who do not operate 
TCP/IP hosts would be able to 
connect into a local node 


and then use TELNET to 


navigate the network and ane 
get to other hams and 


servers. This gives us the ability to use 
the better features of TCP/IP for 
networking while still leaving the 
network open to AX.25 users. 


Why not NOS everywhere? 

When building a network of many 
sites one of the driving factors in new 
amateur participation is that the 
newcomers can have fun with the 
existing equipment. One thing that 
amateur radio operators find fun about 
packet is hacking around the network 
and seeing how the radios are used. In 
a NOS network this is not necessarily 
possible. It takes a deliberate effort of 
the sysop to make this information 
available. That plus the fact that NOS 
is complex might dissuade a newcomer 
from adding to the network. That alone 
is a major contributing factor to why 
TheNET is so much more common in 
amateur radio network building than 
TCP/IP. 

Another feature of NOS which may 
be causing a problem with amateur 
radio network builders is that when a 
user establishes a TELNET session with 
aremote NOS host the user is asked for 
his callsign. Each time the user steps 
to a new node (while navigating or 
playing) the user is asked for his 
callsign. There is no sure way for a 
concerned observer to trace back 
through the network to find the original 
callsign or origin NOS site for an 
observed user. Since amateur radio is a 
self-policed body it behooves us to 
provide a mechanism for such 
traceability. Thisis not a built in feature 
of any TCP/IP software at this time. 

Other things that need to be improved 
with NOS are it's documentation, ease 
of set-up, and the availability of off-the- 
shelf single board solid state machines 
that perform the duties of a NOS 
network node. A program for TNCs 
which does TELNET wouldn't hurt 
either. There is a light down the tunnel 
(hope it isn't an oncoming train hil). 
There are now two solid state NOS 
hardware platforms. The Kantronics 
Data Engine and the Gracilus 
PacketTen. One or both of these may 
alleviate these objections. Then look out 
TheNET! 


—KA2DEW 
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CROWD: Conference Nodes 


One of the TheNET software versions available al- 
lows for a roundtable or conversational type of QSO 
between multiple stations. NEDA has made the use of 
node sites equipped with this software easy to recognize 
by giving these special feature ports a distinctive name. 
NEDA converse ports are all called CROWD regardless 
of their callsigns or location in the network. This makes 
it extremely easy for keyboard users to find and access 
a particular CROWD port for a fun time keyboarding 
with other packeteers. All a user has to do is connect 
to any node that hosts a CROWD port and type C 
CROWD to be automatically connected to the local 
CROWD port. 


The usage and commands for these ports is extremely 
easy to learn. The main commands are all proceeding 
by a forward slash line “/’ and are entered on a line by 
themselves in order to be accepted as a valid command. 


The commands and what they do are as follows: 


/2 Help 

This is the HELP command. It will give you a page 
full of commands and what they do. You may also enter 
a/H to get the same thing. 


/W Who 

This stands for WHO and will give you a listing of who 
is logged onto the CROWD port and what channels they 
are on. There are 255 channels on each crowd and each 
channel can theoretically have 255 users. 


/M Message 

This is the command to send a *PRIVATE* message 
to another station who is logged onto the same channel 
that you are. Usage syntax is: 


/MWA2TVE Hi Howie, nice to see you here! 

Where WA2TVE is the station to whom private text 
is sent and the line of text that follows will be the pri- 
vate message. The sent text will only be seen by 
WA2TVE. 


IC Channel 
In order to change channels you would use this com- 
mand. 


When Ist logging onto a CROWD you will be on 
channel zero. To change to another channel you send 
the slash C followed by a space and a number between 
1 and 255. See the helpful hints for suggestions on 
gentlemen’s agreements regarding channel usage. 


IT Invite 

If you wanted to invite someone to join you on whatever 
channel you are on use this command. Syntax is slash 
I followed by a space and the callsign of the station you 
want to invite. That station will get a one line blurb 
asking him to join you on whatever channel you sent 
the invite command from. 
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/B- Bye 


Or if you prefer a /Q for QUIT. This logs you off the 
CROWD port and disconnects your stream into the port. 


One last operational point on CROWD usage is that 
you must send at least a <return> command after con- 
necting to CROWD for it to actually enter you into its 
list of users and show you as logged on. For convenience 
sake the best thing to send after getting the initial 
connection back from the port you are accessing is the 
/W command. This will not only get you initialized on 
the CROWD but also show you just who is logged on and 
already there. 


Helpful Hints about CROWD nodes 

The following usage conventions are suggested as good 
operating practices when using a CROWD node in the 
N.A.P.R.A. Network. The conventions are designed to 
keep loading to a minimum while allowing the most 
effective use of any CROWD port. 


1> When you have more than three users on a CROWD, 
move the group to any channel except channel zero. 
This makes it possible for a new user to log in and 
see the/H or/W command without being bombarded 
with traffic from your existing conversation. 


2> At some times during your operation on CROWD 
you might find that other people’s response to your 
comments are delayed so long that conversation 
becomes unfriendly. When this happens do not send 
lines of remarks regarding this phenomena. At 
least, don’t send it in an open message. Take ad- 
vantage of the /m feature when the CROWD seems 
to be terribly slow. Otherwise it'll just get slower. 


3> Keep an eye out for new users, who are easily con- 
fused and haven’t learned how to use the CROWD 
node yet. It is best if someone instructs a new user 
by chatting with them on channel 0 before drag- 
ging them up to an active QSO channel. This con- 
cept alone is reason enough to leave channel 0 clear 
most of the time when the crowd is in use. 


<*PRIVATE*> messages can still be seen by 
other people, particularly from the various USER 
ports it finally comes out on. Be discrete and use 
operating and conversation habits that act like 
everybody is listening, as if you were operating 
any other amateur mode. 


4> 


5> The node ops of the network nodes are responsible 
for making things run right. Don’tbe afraid to send 
packet mail to the sysops of a particular site to re- 
port a problem or irregularity. Use the INFO com- 
mand at the user port of the site hosting the 
CROWD to ascertain the site operator. Node ops 
would rather get several complaints about system 
problems than not know that anything is wrong. 


N.A.P.R.A. Notebook v1.0 
© NAPRA 1992 


9> Extreme “upper” channels have been suggested as 
places to hang out when waiting for a sched (IE: 
above channel 200). If it seems that stations are 
hiding up in the 200 range it is probably because 
they aren’t able to pay as much attention to the 
conversation as they would have to if they stayed 
on the active channel while waiting for their sched 
(specific stations). 


10> If you log into a CROWD, stay there for at least 
several minutes! Sometimes when the network is 
loaded, it takes several minutes for traffic to travel 
through the network and then another couple of 
moments for the station monitoring the CROWD 
to get back to you. 


11> If a CROWD is inactive, feel free to leave a stream 
from your TNC on channel 0 waiting for someone 
else to log in while you tinker in the network on 
another stream from your TNC. This way some- 
one else might check in and find you on the CROWD. 
This is a great way to meet people and to promote 
keyboard to keyboard conversation. By the way the 
current ‘no activity time-out’ on CROWD nodes in 
the network should be 2 hours. The good news is 
that you can leave your terminal on in your shack 
and work on something else. The bad news is that 
if you walk away people will be saying “Fred? You 
there? Fred? hellloooo? Fred??” until your two 
hours is up!!! 

12> Don’t get stuck in arut. There are CROWD nodes 
at many of the network sites (and some outside of 
our network). Try them all, what the heck, try them 
all at the same time! (and hope that you are well 
practiced at keeping your TNC streams straight!) 
See NAPRA user port maps for CROWD sites. 


13> If an emergency net starts up on the CROWD port 
that you are using the net control station may ask 
stations to either log off or move to certain chan- 
nels for various purposes. Please comply as all of 
the capacity of the network may be required for 
emergency traffic. The CROWD nodes (and ama- 
teur radio) are here primarily here as an emergency 
resource. We just have fun with it in mean time 
and hope that we never have a real emergency. 
Running your own CROWD 
Once you have a multiport node set up with at least 
three user ports able to access it via backbone links a 
CROWD node may be added. If aCROWD node is added 
to a lesser network it only adds to the frustration of the 
users. The CROWD node is a TheNET chip similar to 
that used in network nodes. It runs in a TNC2 and hooks 
up to the diode matrix in your multiport node. The radio 
port is also active and can be used as a backbone port 
although the neither routing info or parameters are 
remote programmable so this is not recommended except 
in emergencies. 
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The CROWD software is available from most of the 
packet Elmers and is normally handled on PC compat- 
ible floppies in binary data form. The Elmer can tell 
you who can burn an EPROM for you if supply a 27256 
or compatible. 


Note that too many CROWDs on a network spread 
the users thinly to the point where they don't run into 
each other anymore. Only if the concentration of users 
is good do CROWD round tables generally start. 


What does it look like? 

Here is an example conversation on CROWD. In this 
conversation Doc, WB2JAB, Tadd, KA2DEW and Pete, 
N2IJW were already talking when KAOPGQ signed on. 
Tadd is recording this so it is seen from his perspective. 
Tadd’s typing is in italics. 
cmd: 

c potsdm-5 

cmd: *** CONNECTED to POTSDM-5 

c crowd 

POTSDM: K2CC-1} Connected to CROWD:KA2DEW-7 

/W 

CROWD: KAZDEW-7> POTSDM CROWD /w->who /h->help!1091 


User Circuit Channel 
WB2JAB CANTON: WA2MZF-5 Q 
N2IJW CANTON: WA2MZF-5 
KA2ZDEW POTSDM:K2CC-1 4) 


a 
Now I’m back on. 


<N2IJW>: YUP, STILL HERE. THOUGHT ABOUT 
GOING TO GREEN N GOLD GAME, BUT 
NOT MUCH DIFFERENT THAN GOING TO 
THAT MIDNITE (12:01 PRACTICE ON 
OCTie5 TH: 
<WB2JAB>: OK WELL EVEN I CAN UNDERSTAND 
THAT ! 
<N2IJW>: DOC, ARE YOU DIGIPEATING THRU ME? SEEMS 
MY RIG IS XMITTING A LOT! 
<WB2JAB>: HOWS THE JOB GOING PETE ?????<< 
<WBZ2JAB>: NO PETE I AM TO ‘CANTON’ V MNY THEN 
<WB2JAB>: CROWD. .777777777?? 
<N2IJW>: IT’S GOING WELL. FEW CHANGES SINCE I 
BEGAN, BUT ALWAYS LOOKING UP. AM SURE 
GLAD THAT I MADE THE CHANGE IN JOBS. 
<N2IJW>: OK, SOUNDS LIKE GOOD PATH. 


I think that that old job sounded pretty 
bad Pete. You can WALK to work now. 
<N2IJW>: YES, I WALK ALMOST EVERY DAY. EXCEPT THE 
DAYS WHEN THE WEATHER SERVICE REALLY 
BLOWS IT. THEY CALL FOR RAIN, I DRIVE, 
AND THE DAY IS SUNNY!! 

YOU STILL GOING TO WORK DAILY PLANET AT 
THE GAMES PETE 7??? 


<WB2JAB>: 


<N2IJW>: DON’T THINK SO, DOC. CAN ONLY FLY FOR 
FREE FOR THAT ONE YEAR. ALTHOUGH I 
HAVEN’T ASKED GARY MIKEL ABOUT IT. 

<WB2JAB>: TADD HOW MANY CHANNELS IS ON CROWD ?777? 

<N2IJW>: RIGHT NOW, THERE’S A DUMB SHOW ON TV... 


WILL HAVE TO CHANGE THAT! 

It’s got 255 channels but it can only 

handle 32 users. Pretty dumb eh? 

*** KAQ@PGQ signed on 

Howdy PGQ! Tadd here. 

<N2IJW>: HOWDY...PETE HERE. 

<WB2JAB>: HELLO KA@PGQ HOW’S BY YOU, & WHAT’S NEW 
IN’ THE *Z00” 222 

<WB2JAB>: MY NAME IS “DOC” QTH IS WINTHROP, N.Y. 
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<KA@PGQ>: zoo??? the only zoo i know is the one i 
left in germany. Am now at Drum. 

How long were you in Germany? 

Also how long are you going to be at Drum? 

<N2IJW>: PGQ, WHAT’S YOUR NAME? GERMANY, DID YOU 

LIVE THERE? 

ok there is tod,pete,doc..... 

Like we are missing snow white 

<KA@PGQ>: name here is rob 

<KA@PGQ>: i will be here for a while 

Tadd, you cretin! 

<KA@PGQ>: and i am not shure how long i will be 

here 

HI ROB NICE MEETING YOU OM. 

1 wuz in da land for 3.5 

ROB, DO YOU SPEAK GERMAN? 

call there was/is da2x1 

1 was in giessen which is north of 

frasnkfert 

sprect bissen doitch 

HAY TADD CAN LINDA COME TO THAT MEETING 

SEHR GUT! ICH SPRECH SEHR GUTES DEUTSCH, 

ABER NUHR NICH MIT SCHRIFT!! 

<KAQPGQ>: 777777? cat got ur tung???? 

Sure thing. It’s an open meeting. 

probably be > 2hrs long tho. 

<KA@PGQ>: youbetcha 

We can send out for pizza if it gets too 

late. 

We’ve got the room until 9PM. 

<N2IJW>: ROB, MY GERMAN IS FLUENT, BUT NOT IN 
WRITTEN-FORM! 


<KAQ@PGQ>: sounds 


<WB2JAB>: 
<KA@PGQ>: 
<N2IJW>: 

<KAQ@PGQ>: 
<KA@PGQ>: 


<KA@PGQ>: 
<WB2JAB>: 


<N2IJW>: 


Etat 


MAKE IT...AND HOPEFULLY KRISS IS COMING. 
TADD, SEE ROB KNOWS WOOF! 

i like cats 

i wont be able to do anything tomorow i 
have 24 hr phone watch 

here kitty kitty kitty 

WELL LINDA HAS BEEN AT K2CC BEFORE TADD. 
TADD, LINDA MIGHT BE ABLE TO ACT AS A 
GUARD-DOG.... 


<N2IJW>: 
<KAQ@PGQ>: 
<KAQPGO>: 


<KAQPGQ>: 
<WB2JAB>: 
<N2IJW>: 


MIght? 
110# and you say MIGHT? 
AAAAAAAAAAAAAAAAAH 
JW 
User 
WB2JAB 
N2IJW 
KAZDEW 
KAQPGQ 
* 
Well enough of that. Conversation on the CROWD 
that night ranged from talk about race cars, to guns, 
saxiphones, radios, packet, dogs, food, you name it and 
the conversation lasted for about 3 hours, It’s a lot of 
fun. Join the CROWD.. If nobody is on when you get 
on just hang around. Leave CROWD on when you are 
working around the shack. If you do that every evening 
and anybody else does too they you've started a CROWD! 
Here’s a copy of the help file from CROWD: 


NEDA *CROWD* port Commands are: 
f? Print help information 


Circuit Channel 
CANTON: WA2MZF-5 
CANTON: WA2MZF-5 
POTSDM: K2CC-1 


WATERT : KA2QJ0-5 


i) 


WB2JAB>: BY THE WAY ROB LINDA IS 3, & WEIGHS /BYE Terminate the convers session 
= se ABOUT 110#. /CHANNEL n Switch to channel n 
3? 110#?? That’s hard to handle. /EXIT Terminate the convers session 
<KA@PGQ>: what are you all runnin? i have a KAM /HELP Print help information 
and a tandy laptop PC runnin pacfile /INVITE user Invite user to join your 
<N2IJW>: <<<<ccc<<< AND LOVES MILKBONES!!!!'tttt! channel 
I’m using a Mac with a PacComm Tiny 2 and /MSG user text Send a private message to 
a Kenwood into a dipole on the roof. Users 
<WB2JAB>: WELL SHE DOES HAVE A MIND OF HET OWN ! /QUIT Terminate the convers session 
<N2IJW>: HAVE A TELEVIDEO-95@ DUMB-TERMINAL, WITH “WHO List all users and their 
A PAC-COMM TINY HERE. channel numbers 
<KA@PGQ>: 110 is that kilos ore carrats /WRITE user text Send a private message to 
<WB2JAB>: RIGS ARE: TANDY 100, MFJ-1278, KENWOOD Ms User 
TR 7730 , & A RINGO RANGER 2. 
<WB2JAB>: LBS. ROB GOT SOME TO GROW YET. 
Rob, you going to make the packet meeting 
tomorrow? , 
<KA@PGQ>: see a amcomm radio ... very old fm CROWD node TNC. 
<KA@PGQ>: how tall??? Software for CROWD 
<N2IJW>: RIG HERE ALSO OLD...MIDLAND 13-50 XTAL- is built into this TNC. #PTSDW link to 
RIG. CANTON, TNC 
<WB2JAB>: ABOUT 22", SHE HAS A BIT TO GROW YET, 
BUT NOT MUCH. 
<KAQ@PGQ>: i must work tomorow ... and i have no : Hexipus 
transportation any way diode matrix 
<N2IJW>: TADD, MAYBE ROB CAN CATCH A RIDE WITH to allow 
KA20J0."7 KRISSSUL SHEP SNCOMING OR) “OP ACSE bee. ee feahen 
Yup. It is too late at night to arrange dial 
that though. Sigh, = == San A ERR zag ess: | sets 
<WB2JAB>: BY THE WAY ROB LINDA IS A BLOODHOUND. . talk to each 
<KA@PGQ>: 22" 110 lb 3? what gives???? other. 
<KAQ@PGQ>: 1 must work tomorow i 
<KA@PGQ>: rrr woooffff POTSDM 
<WB2JAB>: ITS STANDARD SIZE FOR A BLOODHOUND ROB.. 
WOOOOOF! 144.99 user 4 Computer for 
BOO nara cean ea AIRE rer oct a Jiueetie 
< > ; E 
ON THE 147.255+ REPEATER, IF YOU CAN SF ee aieeepe packet 
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TheNET Plus 
Node Op Resource 
Manual 


This version of the resource manual by Tadd 
Torborg, KA2ZDEW for v2.10st of TheNET Plus 


Programming: Bill Beech, NJ7P. 
Initial idea and format by Jack Taylor, N700O. 
Some text by Jack Taylor, N700. 


TheNET Plus software by TheNET and TheNET Plus 


Hans Georg Giese DF2AU & NORD><LINK : Y : 
and by William Beech, NJ7P with Portable. Compatible. Public Domain. 


Jack Taylor, N70O Se ecar rps . . , 
The authors deny any responsability TheNET software is public domain, 


for the product or it's use. ONLY for non commercial use. 
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Introduction 


TheNHET is a software package that is installed in many TNCs (Terminal Node Controller) to perform message routing 
in an Amateur Radio Packet network. The entire network is built up out of TNCs running TheNET and attached to by ser- 
vices and users. This manual is a history, theory of operations, user's manual and network manager's manual for TheNET 


version 2.10. 
TheNET Plus Versions 


v2.00 was the prototype test node. The maximum number of calls listed in the Heard list was 10 over a 10 minute 
period. 

v2.01 was the first “official release” of TheNET Plus. The Heard list was changed to a maximum of 20 calls listed over 
a 15 minute period. A parameter was added which allowed the NodeOp to set the maximum number in the 
Heard list to a value less than 20, if desired. 


v2.02 was not released. 


v2.03 was identical to v2.01 with the exception of a bug fix associated with Parameter 24. In v2.01 if callsign 
verification was turned off, it also disabled the N * function. v2.03 corrects this situation. 


v2.04 corrected a problem caused by the fix in version 2.03 and changed Parameters 28, 29, and 30 to agree with the 
SETPLUS utility and the current documentation. 


v2.05 added several new NodeOp convenience features. One was to have the STA LED light when someone connected 
to the node. It was felt this would assist the NodeOp in servicing his equipment while at the site. Another new 
feature was to add three sysop KEY commands, MARK, SPACE and DIDDLE which keys the transmitter and 
turns on appropriate alignment tones. Also added was an ON - OFF remote control capability. One of the 
NODE command responses was changed to Host busy, instead of Host table full when a user attempted to 
connect to the host (a non-allowable function when the host port is active). The Not Found response to an 
unknown node now indicates Not Found: <node alias> to assist those running multiple streams in identifying 
which stream is which. 


v2.06 corrects a long standing routing display anomaly, which takes care of the last known problem. 
v2.07 was not released. 


v2.08 adds connect command disable, #node propagate disable option, adds broadcast via port options and reorders 
parm list. Only 16 parameters are read/write. 


v2.08B makes ROUTES command response show both mnemonic and callsign. 
v2.09 is a debug, beta test only version 


v2.10st adds a disconnect back to last node feature; nodes broadcast on power up; shorter PARM command (P 6 200 
instead of P * * * * * 200); transmission 1s and 0s alternate instead of just flags during key-up delay tx; adds 
parameters for telemetry option; increases number of read/write parms to 23; USER response is modified to add 
level 3 usage display. 


<< This information copied from a document by N7OO >> 


223.48 
link to BBS8Q 


145.07 5 | mS 431.125 
iS KETRNG" node Wy by) 446.050 backbone east 


ie backbone north 


K8QRM home station - 145.07 
Consists of terminal or computer with 
terminal program, TNC, Low power 2 
meter radio and optional base station 
antenna. 
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Forward 
TheNET is a good choice for network building. It has several key qualities which make it a very good choice for 


an amateur radio packet network building block. 
¢ It allows for multiport nodes; 


¢ Backbone routes are easily protected against miscreant abuse while still being monitorable by any ham with 


a scanner and TNC (and appropriate modem) 


¢ It supports DxCluster, TCP/IP, keyboard to keyboard, BBS forwarding; 


e It can be implemented in a harsh environment; 
¢ RF tightness of all digital hardware is easy to assure 
¢ It’s software is stable and mostly bug free; 


¢ Network architecture is verifiable remotely by all users; 


¢ Operating parameters are visible to all users; 
¢ It’s simple; 


¢ It’s cheap (less than $120 per port for digital hardware); 


¢ It’s incrementally upgradable; 
¢ It’s fun for the average user; 


¢ It’s compatible with CROWD conference nodes which may be the single most affective packet recruitment 


device. 


TheNET has been targeted as a poor network building block in the past. This criticism has most probably 
been based on experience with a poorly designed network. It is important, in ham radio packet network 
implementation, that good design practice is followed. This manual has information which is required to build 


a successful TheNET based network. 


Background 


NORD><LINK in Germany created TheNET with the 
first release called TheNET Version 1.0. The software 
was distributed in both EPROM image binary form and 
source code. The software was public domain so other 
software people could join in the project. 


Shortly after TheNET arrived on the scene most di- 
gipeaters were upgraded to be single port TheNET nodes. 
This was deemed desirable because of the store and for- 
ward with local retry feature of TheNET. At that time 
there were very few packeteers and scant services. Most 
hams that used packet at all used it to connect to a lo- 
cal BBS and acquire or leave traffic. The BBSs per- 
formed all of the higher level functions. Users could only 
access BBSs that were relatively close geographically. 
Performing complex routing operations for the purpose 
of accessing remote servers was frowned upon. To the 
average ham it looked like packet was no fun at all unless 
you were one of the BBS ops. In some of the metro ar- 
eas many BBSs were brought on line by the packeteers 
in search of ‘fun’. Because there were very few frequen- 
cies in use, and with cross frequency connections rare, 
long distance connection to a BBS was discouraged. 
There were ego-wars about who could put up a BBS in 
a certain area or on a certain frequency. 
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Because the only implementations of TheNET were 
single port Gust modified digipeaters) and because pack- 
eteers in general were discouraged from adding to the 
existing functional services base, packet growth stag- 
nated. Basically the only way to develop new hardware 
was to create the users group first, and then start working 
on hardware. Many users groups were founded on the 
proposed existence of hardware or software. These 
groups never lasted long and once again the average 
packeteer was abused. 


Packet radio used VHF and UHF spectrum This is 
the best place for automated packet stations and user 
access to BBSs because communications on VHF and 
UHF is more consistent than HF and there is much more 
spectrum available. The best people to work on a packet 
radio ‘network’ that already had experience on VHF and 
UHF are the repeater and FM enthusiasts. Strangely, 
in the early days of packet radio (1980 thru 1988) the 
repeater and FM enthusiasts not only didn’t want to work 
on packet systems but they despised the mere concept 
of packet. They didn’t like packet taking up FM sim- 
plex channels and repeater spectrum and they didn’t like 
the fact that they couldn’t monitor the packet traffic by 
ear. They also didn’t realize the potential of packet ra- 
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dio for long distance shared channel communications, 
an implied packet radio feature that still didn’t exist any- 
where. So the most valuable resource available to ham 
radio packet had declared packet radio networking a non- 
goal, at least for a while. 


Now, back to the BBS ops. After operating a BBS for 
a short time many of those who came in search of fun 
found out that it was actually a lot of work. Some even- 
tually dropped out of packet radio altogether. The re- 
maining BBS ops have generally seen packet radio de- 
crease in usefulness. Some have banded together to 
create better facilities for trafficing their BBS data. 


TCP/IP has seen some popularity, starting in the mid 
80s. TCP/IP offers real time and non real time opera- 
tion modes. Most of the stations involved in that branch 
of the hobby are pure computer science enthusiasts. They 
are in search of amateur radio links to extend the use- 
fulness of their computers. Most do not have a strong 
background in radio, even less than the BBS ops. TCP/ 
IP suffers from a lack of packet connectivity as badly 
as the BBS operations do. 


DxClusters are a creation of AK1A and the Yankee 
Clipper Contest Club (YCCC). This is a product that, 
like a BBS, runs on a PC. Unlike a BBS it establishes 
communication between all available DxClusters and 
attempts to keep the connection up. Users who connect 
to the local DxCluster have access to the stations and 
facilities at all of the other DxClusters. The only flaw 
with a DxCluster network is that it only supports Dx- 
Cluster features. This leaves no room for TCP/IP, DOS- 
gates or compatibility with TheNET, ROSE etc.. Dx- 
Clusters can talk over a TheNET or ROSE network but 
ROSE and TheNET can’t talk over a DxCluster network. 
No effort is made to preserve 2m channels as this seems 
to be very under stressed in the DxCluster literature. 


In the middle of all this are the hams that got onto 
packet for the sake of communicating. These people are 
interested in performing similar operations on packet 
that they would via voice modes. They want to go out 
and find people to chat with. They'd be happy meeting 
the old crowd or finding new hams to talk with. These 
people have been totally frustrated with packet radio. 
Perhaps three quarters of all hams who got into packet 
radio fell into this category. Many have forsaken packet 
radio. Some have decided to do something about it. In 
the north east United States a club was formed of ham 
radio packet communicators. This book is the product 
of their experimentation and successes. 


TheNET has much more potential than it has been 
used for. TheNET allows a network to be constructed 
that is much more efficient than a single port node net- 
work. In order to take advantage of the true power of 
TheNET (or any other of the currently existing network- 
ing software) a proper radio system needs to be estab- 
lished. Carrier Sense Multiple Access (CSMA) is the 
current mode of packet operation in use by hams today. 
CSMA will not work on a system where there are hid- 
den transmitters. In order for a packet radio network 
to function all links to servers and all links between nodes 
must be dedicated point to point links. Only in this fash- 
ion can an environment be created that allows for ex- 
pandability and upgrade. Without this inherent through- 
put, expandability and upgrade path no network will be 
successful in the short run, let alone the long run (un- 
less all contributors are very rich to start with and in- 
finitely high speed equipment is used at the start). Fur- 
thermore the equipment recommended to potential sub- 
scribers must be available off the shelf. If a limitation 
on network subscribers is created by requiring them to 
be software or RF gurus then the network that is cre- 
ated will necessarily exclude those without the required 
skills. A TheNET node may be constructed with entirely 
off the shelf gear. Almost all of the gear can be found 
in any of the common ham radio dealerships. The re- 
maining gear (diode matrix boards and EPROMs) is 
available from several packet groups and is of the small- 
est hindrance to ‘getting started’. 


One of the design criteria that went into TheNET is 
that any packet user on the network is privileged to look 
at the network architecture and to examine a lot of the 
network functionality. The network may also be moni- 
tored with commonly available equipment (except for 
high speed modems). This is a feature that allows new 
network subscribers (node owners) to come up to speed 
quickly. Without this inherent user freedom a lot of 
potential network builders might be turned away, mys- 
tified or feel left out. 


Recently NJ7P, Bill Beech, and N700, Jack Taylor 
designed and implemented changes to TheNET to make 
TheNET Plus v2.08B. Jack and Bill’s purpose was to 
add functionality to give even more support for the net- 
work users. They have succeeded. This document de- 
scribes most of the features and much of the function- 
ality of TheNET Plus v2.08B. Keep up the good work 
Bill and Jack! 


(FTE SES DCE FT NAR PALO OI RL SPT PTDL TE TUE ICT GRE RT I ST TS 
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Theory of Operation 


TheNET is a software package that runs in a TNC2. 
The purpose of the software is to control a TNC ina 
system of TNCs called a network. The network is usable 
by hams running any mode of amateur radio packet 
based on AX.25 protocol. The hams can utilize the 
network to chat in real time, access remote computers, 
pass traffic or perform paging and remote control. Fol- 
lows is a technical description of the TheNET software. 


Hardware - L1 

The TNC2 is a dual port device. That is, it has two 
serial i/o channels. One of these i/o channels is hooked 
to an RS-232 driver and a D shell connector. The other 
i/ochannelruns to the modem disconnect header and then 
to a 1200 baud modem. 


RS232 
line driver 


and routing operations which are written within the 
bounds of the ISO 7 level model. That is that the 
processes in the TheNET software are modularized in 
the following functions: 


L1:1/O control and hardware; 

L2:AX.25 linking; 

L3:network routing; 

L4:transport processor; and 

L7:command processing. 
Link Controller - L2 

The TheNET node’s link controller will accept and 
make AX.25 connects on either the modem or RS-232 
ports. Ifastation connects tothe TheNET node on either 
port the node will remember that a connection is made, 


1200 baud 
modem 


To D shell RS-232 joneen AFSK Audio to FM 
Connector isconnect Transceiver 
Header 


The software that runs in the TNC2 is installed in a 
32K EPROM and is mostly compiled C code. Some small 
sections arej written in assembly language. Also stored 
in the EPROM are default parameters and text strings. 
Generally the text strings are not user programmable 
but a bit hacker could find them and change them. Text 
strings that exist include “Connected to” message, 
command names, “USERS” response string, beacon text 
and error messages. The default parameters, callsign, 
node name and password are programmable. Most 
installers of TheNET Plus 2.08B will be using the 
SET208.EXE program with a PC. 


International Systems Organization (ISO) 

The function of a TheNET node is to act as an active 
data store and forward device as well as a remote com- 
mand interpreter for users. Communications can occur 
both on the modem port and on the RS-232 port at the 
same time. Communications is AX.25 with networking 


the callsign of the connecting station, and the callsign 
that was used to connect to the node. These are saved as 
the address field. The node can accept the connect using 
the preset callsign and ssid in the EPROM or using the 
nodename with any of 16 SSIDs. Connects may be 
accepted by the node from the same callsign on all 17 
callsign - nodename - ssid combinations at the same 
time. The next time a packet is received that matches 
that address field the node will classify the connecting 
station as either a user or as another node. 


Ifthe connection isa user then the user is added to the 
users list and any further communications is passed to 
the command processor. The user may interrogate the 
node for information that it has (see user commands) or 
he may command the node using the sysop commands or 
using CONNECT or CQ. Ifthe user uses the CONNECT 
command he may establish a connection to another node 
or to a user from this node. This is covered later under 
PCircuitn 
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Routing Processor - L3 

If the connection is another node then the next mes- 
sage that follows will contain TheNETese. TheNETese 
is aslang term that means that the communications has 
non printable characters that TheNETs understand. 
More on that willbe covered under Protocol. If the node’s 
link coutroller gets the TheNETese then it marks the 
station as a neighbor TheNET node and passes the 
connection information up to the routing controller. If 
the traffic that is received is destined to another node 
then the routing processor passes it back to the link 
controller to go out to the next neighbor node in the 
chain. A neighbor node is a node that this node can talk 
to directly, either over the RS-232 port or over the 
modem port. 


Transport Processor - L4 

If a neighbor node passes traffic to me (I'm a TheNET 
TNC) that is destined for me then my routing processor 
passes the message to my transport processor. My 
transport processor is responsible for making sure that 
all data that originates here or is destined to me makes 
its way across the entire path between circuited nodes. 
So, if I connect from here to another node that is many 
sites away it is my transport processor that is respon- 
sible for seeing that the message gets there. 


The transport processor gets messages from the net- 
work processor and from the command processor. The 
command processor is hooked to the user. Users can 
connect to a node and then tell it’s command processor 
to connect to another node. Users can tell the command 
processor to connect to another user or server station. 


Command Processor - L7 

The command processor may be instructed with ASCII 
text commands from auser station. Much of the remain- 
der of this manual deals with command processor 
functionality. The important functions needed for un- 
derstanding of the remainder of “Theory of Operations” 
is that the command processor allows the user to connect 
to other nodes via the network over either the modem 
port or the RS-232 port and to stations that are not nodes 
over the modem port. In addition the user can request 
lists of: 


all nodes in the routing table; 

neighbor nodes; 

the best three neighbor nodes for a particular node; 
all L2 connected stations known to be users. 


Program Start-up 

The program starts up when power is applied. It 
lights the STA and CON LEDs for a second and then 
turns them off. Itinitializes its memory, copying default 
parameters unless it has what it thinks are valid param- 
eters and INFO message in RAM already. Then it sends 
a beacon message on both the modem and RS-232 ports. 
The node broadcast timer is started. 
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Routing 

When the routing processor gets a packet to send out 
it looks at the destination address provided by the 
transport processor. The destination address is the 
callsign of the requested destination node. The routing 
processor looks up the node in it’s node database (rout- 
ing table). It will find up to three neighbor node callsigns 
which are in the direction of the destination. These 
neighbor nodes are routes to the requested node. If the 
requested node is unknown the message is thrown out. 
The information supplied with each route is the callsign 
of the neighbor node, the port number of the route, the 
quality value associated with the path and a flag indicat- 
ing that a route is already in use. If no flag is set then 
the router selects the highest quality route and sets its 
flag. The port number describes whether it’s an over the 
radio shot or an over the RS-232 shot. This information 
is passed to the link manager. 


Slime Trails 

The router knows of up to 100 nodes (adjustable) and 
knows of up to 3 routes per node. If a message, whose 
origin node is not in the routing table, is passed to the 
router, the router notes what neighbor node and port 
sourced the message and installs the origin node and 
route into the routing table. This way when an answer 
to that message comes back through the node the node 
will know what to do withit. This function is called slime 
trailing and only happens in the event that the origin 
node knows of destinations within the network, and 
where the network doesn’t know of the origin node. 
Important: If the routing table already has 100 nodes in 
it then a slime trail cannot be added. 


The reason that this function is called a slime trail is 
that when a user requests a copy of the routing table 
(nodes list)the slime trail shows up on the nodes list with 
just the callsign. Ifthe user traces down the origin node 
by using the N command with the callsign as the 
parameter the user will step through nodes until he 
reaches the origin. At each step there will be a node 
listed with just the callsign. At each node along the route 
the slime trail route will time out randomly based on 
internal TNC timers. 


Nodes Broadcasts 

Every 30 minutes (parm adjustable) the node will 
send a nodes broadcast via both it’s RS-232 and modem 
ports. This broadcast allows the neighbor nodes to 
maintain their databases of nodes that this node is 
sourcing. The broadcast consists of all of the nodes 
whose obsolescence counts are equal or greater than the 
“Obsolescence counter, minimum for broadcast” param- 
eter, all of the nodes whose obsolescence counts are 0 
(locked nodes), and only those nodes whose quality is 
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greater than minimum quality to broadcast. The format 
and order of the nodes broadcast is basically: 

This node, PQ=256 

knownnode, PQ=nodequal 

knownnode, PQ=nodequal 

knownnode, PQ=nodequal 


nodequal is the highest of the 3 values that the node 
has stored for knownnode. 


Broadcasting node 


Nodes that hear 
the broadcast 


When a node receives the nodes broadcast in goes 
through the following program sequence: 
Check if route to the neighbor we are hearing Is in place. 
No? Then use parameter 2 or 3 depending on if this is RS- 
232 or HDLC and put the neighbor node in the route list. 
Apply the route quality for the neighbor we are hearing, to the 
received nodes broadcast. 
As each node is clocked in store it in the routing table under 
the node's callsign with the route indicating the neighbor we 
are hearing. 
As each route entry is being stored in the routing table, set 
the obsolescence counter to the initialization value in the 
parameters. If the route to the node we're storing is locked 
in, then ignore the incoming information. 


Circuits 

The process of connecting into a network node, across 
the network, and then out of the network requires three 
operations. The first is called an uplink. The second is 
called a circuit and the third is called a downlink. The 
uplink and downlink stages are AX.25 connections to 
the link processor of each of the two end nodes. The link 
processors pipe directly to the command processors. 
Circuiting means that the command processors pass the 


traffic to the transport processor which then passes the 
traffic to the router etc.. 


After the router in the origin node gets traffic to go to 
some distant destination node the traffic can hop from 
node to node over more than a dozen TNCs before again 
reaching a transport processor which will be at the 
destination node. The destination transport processor 
will then acknowledge the packet and the process is 
repeated in reverse. At the same time the destination 
transport processor acknowledges the message it sends 
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the message to the destination command processor. If 
the origin transport processor hasn’t gotten an acknowl- 
edgment before a time-out timer expires (transport 
time-out) it can resend the message. If the origin 
transport processor gets another message from the 
origin command processor it can send that one into the 
system as well. It can have up to 4 messages in transit 
without having acknowledgments. When the command 
processor attempts to send the 5th message the trans- 
port processor will respond with a ‘choke’ flag. 
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Using a TheNET Network 


There are two common modes of using a TheNET 
network. These are broadly called level 2 access and 
level 4 access. Most users will only be concerned with 
level 2 access. The level number refers to the ISO net- 
working model described in Theory of Operation. 


Level 2 Access 


The user connects from his TNC to the nearest, but 
least busy, network node. This is done using the connect 
command from the user TNC. The node may be ad- 
dressed using either the node's callsign and specific ssid 
or using the node's mnemonic and any of the 16 SSIDs. 
Let's assume that our user is N2MGI and the local node 
is POTSDM:K2CC-1. The following are all valid connect 
commands: 


c POTSDM 
c K2CC-1 
c POTSDM-4 

The POTSDM node will answer any of those. All are 
perfectly reasonable ways to connect to the node. The 
reason that the node allows this versatility is that if the 
user can do multiple streams he can connect to the same 
node up to 17 times, or however many streams the TNC 
allows if less than 17. 


In this example the node would answer and a *** 
Connected to message would show on N2MGI'ss screen. 
A monitoring station would observe: 

N2MGI>POTSDM (c) 
POTSDM>N2MGI (ua) 

or 
N2MGI>K2CC-1 (c) 

K2CC-1>N2MGI (ua) 

or 
N2MGI>POTSDM-4 (c) 

POTSDM-4>N2MGI (ua) 

The node will assume any of the 17 identities for the 
purpose of maintaining the connection. N2MGI could, 
on three different streams, connect to all three of these 
identifiers. 


Level 2 Network Use 


After the user has gained access to the node he can 
request a list of destination network sites or he can is- 
sue the Connect command to select one. Then he can 
use the Connect command from the destination node site 
to connect out of the network. The following is an ex- 
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ample procedure where N2MGI might connect to 
KA2DEW using the network. From the command 
prompt N2MGI types: 
cmd:C POTSDM 

Shortly his TNC answers: 
*** Connected to POTSDM 

N2MGI is now connected to the TheNET node 
POTSDM. There are several commands available at 
this time. (See User Command List). For MGI's pur- 
poses of connecting to KA2DEW from CHSTR node he 


then types: 
C CHSTR 

This tells the POTSDM node to pass MGI off to the 
CHSTR node. POTSDM returns: 


POTSDM:K2CC-1} Connected to CHSTR: KiMEA-2 
Once again MGI can enter any of the TheNET user 
commands. To get to KA2DEW he types: 


C KA2DEW 

POTSDM node receives the "C KA2DEW' from MGI 
and passes it offto CHSTR. CHSTRmakes the connection 
to KA2DEW and then sends it's response back through 
the network to POTSDM which then sends: 
CHSTR: KIMEA-2} Connected to KA2DEW 

KA2DEW’ss station, which has gotten a connection from 
CHSTR under the callsign of N2MGI-15 responds to 
CHSTR with a connect text. That text is sent through 
the network to POTSDM which then sends it to N2MGI. 
So: 


Tadd's station. Use KA2DEW-4 for my PMS 
or beep several times to get my attention!!! 


Now any traffic that N2MGI or KA2DEW type will 
be routed back through the network. The network is 
now transparent to the two stations. 


Level 4 Access 


Some equipment that a user might operate or that 
is built into certain server systems is capable of directly 
accessing TheNET through the higher levels of the ISO 
model. In this case the TheNET node would be accessed 
such that it thinks that the user/server is yet another 
TheNET node. The user/server could access the com- 
mand processor at the local or at a distant TheNET node 
or might perform level 4 access direct to another user/ 
server across several nodes. 
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User Command List 


Once a station makes a connection to a node every- 
thing sent into the network will be handled by the node's 
command processor. These are the commands available 
to the user. 


BYE 

This command will tell the node to disconnect from 
the user and may be abbreviated to B. This will have 
a similar effect to the user doing a disconnect from his 
own station. 


CONNECT 

This command instructs the node to connect to an- 
other station. The command is entered as C STATION 
where station may be a six character or less text string 
or a valid amateur callsign. First the node searches it’s 
own database for a match between station and a known 
node name or a callsign associated with a known node. 
If a node name match is found then the callsign associ- 
ated with that node is used. If that is the case or if station 
matches a node’s callsign then a network connect is 
attempted to the requested node. 


If no match is found then the node will process 
STATION and determine if it is a valid callsign. If not 
then the node will send an error message to the user. If 
it was a valid callsign then a connect attemptis made via 
the modem port of the node. If successful the user will 
be sent nodecall:nodename} Connected to STA- 
TION. If unsuccessful the user will be sent an error 
message. 


CQ 

The CQ command is used by a station who wants to 
make a random connection from a node. The node may 
either be the local node, or a remote node. The CQ 
command is sent with a parameter of up to 77 charac- 
ters. The node will send a message with the calling 
station's callsign (-15), to CQ, with the parameter text in 
the info frame. Thus if user NK1M types: 
cq Bill calling from Nashua 

The node will send over the air: 
NK1M-15>cQ: Bill calling from Nashua 

The node only transmits the text once. If Bill wanted 
the text sent several times he'd have to type it several 
times. The node puts NK1M into CQ mode. That means 
that ifit hears anybody trying to connect to NK1M-15 it 
will complete the patch, connecting the new station back 
through the network to NK1M. Additionally while 
NK1M is in CQ mode the USERS list will show NK1M- 
15 as calling CQ: 

Circuit (MONROE:WB2GNR-1 NK1M) <~~> CQ (NK1M-15) 

If a station connects to the node that NK1M is call- 
ing from and then connects to NK1M-15 from the node, 
the node will make the patch. CQ mode times out and 
disconnects NK1M after "No-activity timer" runs out 
(usually 2 hours). See Node Parameters. 
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HEARD 

The H command requests a list of stations that the 
node has heard in the past 15 minutes. Stations that 
are known to be nodes are ignored. The maximum 
number of listed stations is 20. The stations are listed 
in an odd order, not by time. Stations that digipeat before 
they are heard by the node are shown anyway, but 
neither the digipeater, nor the fact that they were di- 
gipeated is indicated. 


INFO 
Sending this command will make the node respond 
with a block of text that will describe the node’s location, 
frequency, who to contact, servers accessible etcetera. 
Examples of info messages are: 
WB2QBQ-1 : KNOX} 
port 144.91 USER 
QTH Knox, N.Y. 
sysop WB2QBQ @ WA2PVV 
phone 518-555-1212 
Maps NEDA Box 563 Manchester NH 03105 


K2TR-10: DXKNOX} 

Port Dedicated DxCluster Link 

QTH RROX GN «vis 

info WB2QBQO @ WA2PVV 

Enter C K2TR for connect to YCCC/AARA DxCluster 
System 


N2CJ-1:CLV} 

Port 145.09 MHz USER access channel 

QTH Clove Mt. Poughkeepsie, NY 

spnsr N2CJ @ WB2COY 

servers pls use 441.0 for network access! 


For server info C BBSCOY DN CLVSERV.TXT 


NODES 

This command gives the user access to the routing 
table in each node. After connecting to a node a user can 
use N, N *andN <alias or callsign> to get in- 
formation from the node about it's routing table. 


The NODES command (abbreviated N) returns a list- 
ing of the user port nodes contained in the routing table. 
It gives a user a listing of possible destination nodes for 
him to connect to. 


N 
SRTGA1:WA2UMX-1} Nodes: 
WA2PVV WA2UMX-4 BBSUMX : WA2 UMX 


KINDER:WA2PVV-7 NEDALB:WA2WNI-3 
OTSEGO: W2SEU-1 SCROWD : WA2UMX-7 SRTGA2 : WA2UMX-2 
SRTGA5:WA2UMX-5 SRTOGA:WA2UMX-14 WMA220:K1FFK-2 


The listings which include a six character (or less) 
mnemonic followed by a callsign are nodes whose in- 
formation was received via a node routing broadcast. The 
listings which include just a callsigns are nodes whose 
information was received in order to create a return path 
to a otherwise unknown node. This function is called 
Slime Trailing and is described in the Theory of Op- 
erations. 


GFL: N2AYY-1 
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The NODES * command (abbreviated N *) returns a listing of all of 
the nodes contained in the routing table. This includes the # nodes. (See 
Selecting Mnemonics) 


N * 
SRTGA1:WA2UMX-1} Nodes: 
WA2PVV WA2UMX-4 #GFL10:N2AYY-10 #SCR10:WA2UMX-10 


KINDER: WA2PVV-7 
SRTGA2 : WA2UMX-2 


#SCR11:WA2UMX-11 BBSUMX:WA2UMX GFL: N2AYY-1 
NEDALB:WA2WNI-3 OTSEGO:W2SEU-1 SCROWD:WA2UMK-7 
SRTGA5 :WA2UMX-5 SRTOGA:WA2UMX-4 WMA220:K1FFK-2 


The N command can be used to determine the neighbor node and 
quality for a particular node. The syntaxisN <alias or callsign>. 
An example: 


Weare at the CANTON node and wish to know the route to POTSDM. 
We issue aN POTSDM command and receive back this response: 
CANTON :WA2MZF-5} Routes to: POTSDM:K2CC-1 
> 128 3 1 #NEDA:WA2MZF-11 

81 3 1 #NEDA:WA2MZF-10 

This tells us there is a route to POTSDM and it is an RS-232 path (the 1) via WA2MZF- 
11 which is a backbone node and this route is currently in use. The numbers given in 
the N <alias or call> command will be explained later. Here we just want to show how 
the N <alias or call> command is a powerful tool to help one navigate throughout the 


network. 


PARMS 

(Parameters) Issuing this command will yield a status listing of the 
nodes parameters. There are 32 parameters although only 15 are 
answered with by the PARMS command. The other 17 are only visible 
during node EPROM setup. 


This isa serious bug as in this version of TheNET the users can't access 
ALL of the node’s operating parameters. Hopefully this will be fixed in 
later versions 


The node response may look like this: 
POTSDM:K2CC-1} 50 0 203 3 4 1800 41101035201 

The convention is to number the parameters from left to right so 
parameter #3 is a203. Each parameter affects the node operation in one 
way or another. See the section titled Node Parameters for a complete 
description of the parameters. 


USERS 

This command allows a user to find out who else is using the node. 
This command also reports on network activity in and out of the node. 
The format of the command is simply U <return>. The node will re- 
turn something that looks like this: 
LYNNWD:K7QRM-3} TheNet Plus 2.10st (713) 
Uplink(NONDO) <-L4-> Downlink(NONDO N7WRI) 
Circuit (N5KGP-1 NS5MYI) <-L4-> Circuit (ONT: VE3KYZ-4 NSMYI) 
Thrulink(BISBEE:WA7KYT-1) <-L3-> Thrulink (ONT: VE3KYZ-4) 


Circuit (SVALAN:N700-4 K1SC) 
Uplink(DF2AU) <..> CQ(DF2AU-15) 


The first line identifies the node type and version. The number in 
parentheses indicates the free buffers (36 byte segments) currently 
available. The amount of free buffers varies and is dependent upon the 
total destination and neighbor nodes listed in the tables, as well as the 
number and activity of it's users. Free buffers can be used as a health 
indicator. Upon initial startup, the value will be in the 720 range. Around 
the 450 to 500 area, free buffer depletion may cause the node to respond 
with a Node busy to command requests. 


Version 2.10 introduces the <-L3->, <-L4-> symbols and the term 
"Thrulink" to the USERS display. In the example above, the term 
"Uplink" refers to an OSI level 2 connect from a local user to the network 
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node. "Downlink" is defined as an OSI 
level 4 network connect to a local user. 
A "Circuit" is either an OSI level 4 
network connect from a source node to 
the local node, or it may be a connect 
from the local node to a destination node. 
"Thrulink" displays an OSI level 3 cir- 
cuit from a source node to a destination 
node. As a level 3 circuit, there may be 
more than one user traversing it bi- 
directionally from end-to-end. User 
identity can be accomplished by con- 
necting to either of the nodes listed and 
performing a USERS command. Inac- 
tive level 3 circuits will timeout after 5 
minutes. [This text was taken almost ver- 
batim from N70’s v2.10 cbament. -ad] 


An important note about the level 3 circuits 
display. If you see any level 3 circuits on a user 
port it means that there is a routing problem in 
the node stack's RS-232 matrix or that someone 
is hacking a node to node link through the port. 
This kind of operation is unusual, to say the least, 
from a user and it is probably a clue that a server 
is operating on that frequency. This would not 
bode well for user access performance. This kind 
of problem cannot occur with a properly config- 
ured Local Access user port. 


ROUTES 

This command yields a listing of all 
radio line of sight or wire connected 
nodes that are directly worked (at level 
2) by the node. These nodes are called 
neighbors. The listing will also show 
nodes and digi routes set by the sysop 
locking commands, Due tothe different 
protocols involved, TheNET does not 
recognize KA-Nodes, ROSE nodes, or 
TEXNET nodesin it’s routes list. It will 
recognize GBBPQ, MSYS and compat- 
ible TCP/IP nodes. A typical routes 
display may look like this: 
CANTON: WA2MZF-5} Routes: 

1 #NEDA:WA2MZF-12 203 16 

1 #NEDA:WA2MZF-10 203 3 


> 1 #NEDA:WA2MZF-11 203 12 
0 HULL: VE2RBH 50 1 


In column one we see a 1 for all paths 
that are through the matrix and a 0 in- 
dicating aradio path to VEZRBH, HULL 
node. The right arrow indicator tells us 
one of the paths is either in use or has 
had activity within the past 15 minutes. 
All radio paths show a standard path 
quality value of 50 (This is a standard 
user port). All RS-232 paths show a 
path quality value of 203. The last col- 
umn indicates the number of nodes 
sourced from this route. 
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Sysop Command List 


In addition to the user command listing given above 
there are a special set of commands for System Operator 
use. To be able to use these, you will have to be recog- 
nized by the node as a sysop. The method for doing this 
is described below in the SYSOP command. It is also 
possible to use these commands through the RS-232 port. 
See above. 


SYSOP 

After connecting to the node by issuing a “C callsign” 
command, type “S”. S will return you a random series 
of five numbers separated by spaces. Each number re- 
fers to a single character in the password string. 1 refers 
to the first character. 22 refers to the 22nd character. 
All you do is type the five characters indicated and then 
hit <return>. The node will not tell you that you have 
been successful. This would be too obvious to a listening 
station. You can actually run the SYSOP command 
several times, correctly answering only one password 
and falsely answering the rest. A listening station won't 
be able to figure out which one you answered correctly. 


To test the success of your SYSOP command, type P. 
This will give you a string of numbers, representing the 
default values for the various node parameters. Note the 
value of the first number (typically 50). Now type P 1 51 
If successful, the first parameter should have the new 
value 51. Again type P space and insert the original 
number back in the parameter listing (P 1 50). 


Sample password string: 
FRED WAS A BIG HERO AROUND HERE UNTIL TH 


I usually write out my password strings in a matrix so 
they are easy to translate: 


x®@ x1 x2 x3 x4 x5 x6 x7 x8 x9 
Oar R E D Wi Aes 
TN Gof \ B I G HULEAIR + 0 
2x A ROU N OD Hine 
BX eo RoE Ui Nees Tee Eel: T 
4x H 


Remember that the first valid digit is 01. So, the 
following exchange would properly sysop the LYNNWD 
node: 

SYSOP 
K7QRM: LYNNWD} 31 13 40 01 08 

The 31 indicates the 31st character in the password 
string. From the matrix we get the second character 
from the 3x line. The first character is character 30 and 
is aR. The second character is character 31 andisan E. 
Next we get character 13 from the 1x line which is an I. 
Continue for all five characters. Note that the node will 
not return a number that represents a space character. 
So, I type: 

EIHFS 


The node won't respond to this so in order to verify 
that I got in I type: 


I? 

K7QRM-1:LYNNWD} 50 50 230 3 4 1800 6 1810 35 2 
0 1100 7 200 2 1 180 2 

PemeS & 


K7QRM-1:LYNNWD} 51 50 230 3 4 1800 6 1810 35 2 
On te LOOr7e200n2) e175 1802 

Bes 6 

K7QRM-1:LYNNWD} 50 50 230 3 4 1800 6 1810 35 2 0 
1 100 7 200 2 1 180 2 


Note that the first parameter changes from 50 to 51 
and back to 50. It doesn't change then you have the 
wrong password or you didn't respond correctly. It is 
very important that the parameter is changed back! So, 
if you do this procedure don’t change the first parameter 
by too much. If you were to change it to 255 and then 
weren't able to change it back (Your tower just blew 
down) the node would soon become useless. 


Asuggested alternate way to record password strings 
is with the character numbers on the line above the 
password. This lets the sysop record several passwords 
on one page. Example: 

Y) See Let 55" 20M ENS SEBO Se35h" 440 
| | | | | | | | | 
FRED WAS A BIG HERO AROUND HERE UNTIL TH 


KEY 
KEY MARK; KEY SPACE or KEY DIDDLE 


Operates the PTT line of the TNC and turns on the 
Mark (high) tone, the Space (low) tone or a diddling 
between the two tones for approximately 22 seconds. 


The purpose of the key commands are to make the 
NodeOp’s job of setting deviation and RF frequency 
much easier. Previously it was necessary to reinstall the 
original TNC firmware chip and perform the CALIBRA 
procedure in order to set FM deviation. Now if the node- 
op has the appropriate equipment and is within radio 
range of the node, he can routinely check frequency and 
deviation remotely! At the site, this same procedure can 
be done via the host mode interconnect. Once entered, 
there is no way the KEY command can be terminated 
until the internal timer runs it’s course. If the node 
watchdog timer is set for less than a 22 second duration, 
the watchdog will unkey the PTT. However, the node 
will continue the KEY command until the remaining 
time has expired. During this period, the node will not 
execute any other commands. 
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INFO 

Allows the sysop to enter text into the soft coded INFO 
section on the node. This INFO section has available a 
maximum of 160 characters. Up to 80 characters on one 
line is allowed. It is always a good idea to start any info 
string with a blank line feed to allow your info text 
message to be formatted nicely on the user’s screen. This 
is done by entering a control A on the first line as shown 
below. The reason a control A is used is that a control A 
is an innocuous character that will invisible to most 
users. Note that a “I” followed by just a ctrl A will blank 
the entire info message. For text to be entered on the 2nd 
and subsequent lines, type: I +<text> until the total 
160 character limit is reached. 


As this technique is different than previously used, a 
little in-house practice is advised until you become 
familiar with it. Review the INFO format examples 
previously given for ideas on how you want to set the 
INFO text format. An example for setting INFO: 


Sysop action: I ctrl A 
sign) 
Node response: 


<return> (notice, no + 


ALBANY : WA2WNI-1} 

Sysop action: I +port 144.93 USER 
Node response: 

ALBANY : WA2WNI-1} 

port 144.93 USER 

Sysop action: I+cnty Rensselaer 

Node response: 
ALBANY : WA2WNI-1} 

port 144.93 USER 
cnty Rensselaer 
Sysop action: I +QTH 
Node response: 


West Grafton, N.Y. 


ALBANY : WA2WNI-1} 

port 144.93 USER 

cnty Rensselaer 

QTH West Grafton, N.Y. 

Sysop action: I +info WA2WNI @ WA2PVV 
Node response: 

ALBANY : WA2WNI-1} 

port 144.93 USER 

cnty Rensselaer 


QTH West Grafton, N.Y. 
info WA2WNI @ WA2PVV 


This process can be repeated until the maximum of 
160 characters, including non-typing and punctuation, 
has been reached. 


The key things to tell your connecting stations are: 
What frequency the port is on; 
What type of port it is; 
Where it is located; 
How further information can be obtained 
about the network or the club; 
Callsign and BBS for the sysop and/or 
sponsor of the node. 
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If all of this information is available then someone in 
your area who wants to link to your node can easily get 
in touch with you. That way network growth can be 
facilitated. 


ON - OFF 

A simplified remote control capability as compared 
with the HIGH LOW commands found in TheNET 
version 1.0. ON turns on the CON LED and OFF turns 
the LED off. In the MFJ 1270B, the voltage sense from 
the CON LED appears on pin 8 of the DB25 connector. 
The voltage sense also appears on the base of Q16, a 
2N3904, the output of which goes to pin 2 of the TTL 
connector. The main caution here is that the control 
switch be capable of passing the appropriate amount of 
current and voltage to the controlled device. Note that 
after doing the wink and blink mod this function is no 
longer hooked up. See the Wink and Blink article in Node 
Sites and Hardware part of this Resource Manual. 


PARMS 

Allows the sysop to make changes to parameters 1 
through 23 over the air. These changes are permanent 
until a RESET command is performed or until battery 
power is removed from the TNC'’s RAM. In order to 
change parameters 16 through 32 anew EPROM must 
be burned. 


To use, type P 1 49 <enter> to change parameter 
1 from 50 to 49, for instance. To change Parameter 4, 
type P 4 245. 


For more parameter information see Node Param- 
eters. 


NODES 

Occasionally a need may arise to modify node entries 
in the node routing table. The sysop command for this is: 
N <call>+<alias><quality> <obs> <port> 
<neighbor> 
For example: 


N WA2TVE-8 + DXCLUS 58 0 1 WA2WNI-7 

In this example the node DXCLUS:WA2TVE-8 is 
added to the nodes list with the node name of DXCLUS 
with a route quality of 58, and obsolescence of 0 (thus 
locking in the node) via the RS-232 port (the 1) and 
routed to WA2WNI-7 as the neighbor. Setting the ob- 
solescence to a non zero value will cause this planted 
node information to be temporary 


To manually unlock DXCLUS, the command is re- 
versed: 
N WA2TVE-8 - DXCLUS 0 0 1 WA2WNI-7 

Note that you can manually remove other nodes, even 
non locked ones, at least temporarily, by using this 
command. The values you use for quality and obsoles- 
cence are not important. Port and neighbor must be 
entered exactly as stored in the nodes list. 
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The difference between the lock and unlock com- 
mands is the minus sign. Setting the obsolescence to 
zero permanently locks the destination node into your 
node routing table. Even if the locked node fails, it will 
still be listed in the node routing table. A failed node 
entered as a locked route on the other hand, will not be 
listed in the node routing table if a corresponding locked 
nodes command has not been used. 


Note that if 3 neighbors report a higher quality than 
your locked quality in a locked node, that your locked 
entry will be shoved off the nodes list and will not be 
remembered. 


The locked nodes command to use if an alias isn't 
specified is: 
N <nodecall>+ * <quality> <obsolescence> <port> 
<neighborcall> 

Usage example: N AK7Z-1 + * 143 0 0 AK7Z-1 


Example: 

In a Northwest node the default qualities for a back- 
bone port are 203 for over the RS-232 and 203 for over 
the radio. The minimum quality to broadcast is also set 
to 50. In this case a node that is part of the system will 
be propated 7 TNCs away. Ifa pair TCP/IP stations have 
a point to point link into TheNET nodes may only be 
two radio hops apart. This will probably not be enough 
distance to connect distant clusters of TCP/IP activity. 
TCP/IP stations utilizing TheNET protocol to commu- 
nicate have a limitation in that each TCP/IP station that 
participates must get a nodes broadcast containing the 
TCP/IP station that will be talked with. To solve this 
problem node locking is utilized at all backbone TNCs 
along the way to artificially boost the quality of the TCP/ 
IP node. One feature of node locking is the ability to 
lock the node in with a different name. See NODE sysop 
command in the TheNET Resource Manual. In this 
manner authorised TCP/IP stations would communicate 
over a longer distance. 


Another example: 

If a node performs a special function at a node site 
or in a certain region it may be locked at a low value so 
that it doesn’t propagate any further than necessary. 
This is the case with CROWD nodes and personal use 
user ports. The reason why CROWD nodes must be 
limited sometimes is that there may be CROWD nodes 
closer together than 3 nodes. If they were not limited 
to a small area there may be a case of more than one 
CROWD node showing up at a single user port. A 
personal node is used when a ham has a node stack at 
his house. In this case the ham may elect to have a user 
port for his own use. That user port would not have a 
radio as it would be audio or direct connected to his 
personal TNC. The name of the user port would be 
LOCAL or JOHN or TADD or something obvious like 
that. In order to keep node lists lengths down and re- 
duce confusion for network users such a port is not propa- 
gated beyond the local node stack. Another way of per- 
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forming this function would be to use the R 2 command 
at the backbone ports at the node stack where the 
CROWD or LOCAL node is located. 


ROUTES 
This command allows the sysop to modify the neigh- 
bor table. 


This command allows routes to specific neighbor 
nodes to be locked in or changed. There may be times a 
node-op will want to modify the path quality value ofa 
route to a given node. 


To permanently add a route to the neighbor route 

table the command is: 

R <port> <neighborcal1> + <pathquality> 

port is either 0, 1, 2 or 3. 

0 means route over radio port 

1 means route over RS-232 port 

2 isa special function which is used to block node in- 
formation for a certain callsign + ssid. 

3 is aspecial function which is used to restrict access 
by a certain callsign. 

nodecall is the callsign of the neighbor node whose 

route you are adding 


pathquality is the value that will be used in the node 
routing broadcast interpretation. See Nodes 
Broadcasts in the Theory of Operation section. 


To unlock the routes or to change the quality value for 
an non-locked route use: 


R <port> <neighborcall> - <pathquality> 

When unlocking a route all of the data in the com- 
mand must exactly match the locked data. To change 
the quality value for a non-locked route simply specify 
the new PATHQUALITY. 


An example: 


R O N2CGY-3 + 143 WA2JWJ-1 

The result of this operation might look like: 
MAL: W2RRY-1 Routes} 
0 DKC:W5YI 50 9 


0 CLOUD: W2VXY 192 43 
0 WMASS:N2CGY-3 143 1! 


Here we see the exclamation mark which indicates a 
locked entry. 


The most common example of locked routes is in a 
backbone link which is supposed to be protected and 
dual ended. You may lock in the neighbor route and set 
the radio channel 0 path quality (Parm 3) to zero. This 
protects against unauthorized backbone use or mis- 
routing caused by propagation or DX. The wanted 
routes would then be locked in at quality 203. This 
means that all nodes sourced from the neighbor will 
have routing qualities based on the 203. See Theory of 
Operation for more information on quality calculations. 
0 DKC:W5YI 50 9 

In the routes list the second value after the neighbor 
callsign (in this case =9) is the number of nodes sourced 
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from the listed route. Ifa route is locked this value may 
be 0, indicating that no nodes are sourced from the 
neighbor. 


Changing the value of an established (but not locked) 
route may also be done with the routes minus command. 
Note that attempts to remove a route which is sourcing 
nodes will not be effective. The best you can achieve is 
to set the route quality to 0. If a node is locked using a 
route you want toremove you must first unlock the node. 
If a node is locked to a neighbor for which there is no 
route, a route will be created automatically at the 
quality with which the locked node is set. 


Using Routes 2 and Routes 3 command 

In version 2.08 and later the ROUTE 2 and ROUTE 
3 command exist. These commands are used for two 
purposes, to stop the propagation of a particular node, 
and to stop network usage by a particular station. Note 
that R 2 and R38 configurations do not show unless you 
are in sysop mode for the TheNET TNC. 


Route 2 

This command is very useful. It provides a straight- 
forward way to stop the propagation of a particular node. 
This is very useful for building a network where all nodes 
are guarenteed reliable for the users. If a node appears 
on the nodes list that is not available for user connect, 
for whatever reason, the node can be removed from the 
nodes table perminently with the R 2 command. Ex- 
amples of this include: 


¢ Anode is sourced via a 2 meter route by a neighbor 
node. You can eliminate direct routing to and from 
your own network node by using the R 2 command 
on the backbone route you have towards that 
neighbor node, without stopping the propagation of 
the remainder of the nodes that neighbor sources. 
The command to do this is R 2 + callsign. To remove 
this lock do a R 2 - callsign. 


¢ You have established a wireline link between a node 
called STEVE:KA2EIA-10 and your user TNC and 
PMS called KA2EIA-0 and KA2EIA-2. You don't 
want STEVE to propagate to all of the nodes three 
hops away. You go to each backbone node leaving 
your site and do the command R 2 KA2EIA-10 + 0 
after working the sysop password. Note that not only 
will STEVE not propagate to any neighbor node 
stacks but you will not be able to connect to those 
node stacks from STEVE. To go both in and out of 
STEVE you'll have to step through the local user port. 
This is usually not a problem. You'll probably set up 
a Fkey or other shortcut on your keyboard to make 
this step. 

Route 3 
This command lets you specify a callsign for which 

all ssids will not propagate. This command also keeps 

that callsign with all ssids from connecting to and passing 


Page 50 


through the node. The most obvious purpose for this 
is to stop an individual from passing through your node. 
This is a most hostile act. The use of this command to 
totally remove an individual is unreasonable. Here is 
the only scenario that I can think of for which the route 
3 command would be used. It's still unreasonable: 


A person is such a lid that he is doing something so 
bad as to merit you removing him from your network. 
That person is ignoring your pleas to stop. 


If you use the route 3 feature to lock him out, he be- 
ing such a lid will probably just change his callsign ( an 
extremely uncool act ) and use your equipment anyway. 
Not only will you have driven the person into doing 
something illegal but you'll have no way at all to keep 
track of his activities. Don't lock him out. Use peer 
pressure. If the act is so bad you'll have peer pressure. 
Don't lock him out. Remember, you are the controller 
of a networking resource so valueable that this person 
has to use it even after you've threatened him with peer 
pressure. If your equipment is that useful to him it's 
usefull to his peers too. 


An example of things that are real bad to do to 
somebody's node are: 


¢ Connecting to a local coverage user port on 2 meters 
and sending in lots of data on a regular basis; 


¢ Connecting to a node, then connecting to another 
node, then back to the first, then out, then back, then 
out, then doing lots of NODE commands; 


e Attempting to solve the password for the SYSOP 
command by repeated attempts; 


¢ Using one's own node to flood a node with L4 retries 
at a high rate [this one can be fixxed using the route 
2 command by locking down just the offending node's 
callsign and ssid]. 

In none of these cases is the best thing to do to lock 

the person out. 


RESET 

This command causes the routes table and nodes 
table to be cleared, along with the info message. Any 
currently connected users are lost. This command 
should be run after changing out the firmware EPROM 
or if any problems develop that can't be solved by other 
means and must be attributed to the TNC's digital 
section. 


Since this command must be done over the air and 
since the RESET command causes an immediate CPU 
reboot the node will not disconnect you, or acknowledge 
the command. You will find yourself hung and must 
manually disconnect. Eventually the origin node you 
used will time out or detect a failure and disconnect you. 
Remember to put back the info text and any custom 
parms/routes after you reset a node. 
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Node Parameters 


This section attempts to give meaning to the param- 
eters which control timing and network routing in a 
TheNET node. These definitions are in the order of 
parameters used in TheNET Plus v2.10 but are valid 
(though out of order) for all other TheNET software 
versions. 


1. Minimum quality 

This parameter sets the minimum value for quality 
for a node to be saved into the routes table. This also 
may be called a filter value. This restricts the number 
of nodes that are saved into the nodes table based on 
their quality. Making this value higher reduces the 
number of nodes, making this value lower increases the 
number of nodes. When a node hears a nodes broad- 
cast from a neighbor node it processes that broadcast, 
in terms of the quality value associated with that neigh- 
bor node. Any nodes learned about whose resultant 
quality is less than minimum quality are ignored. Ifthe 
quality to all backbone nodes is the same, regardless of 
path type or port number the length of the network can 
be predicted based on the path quality and minimum 
quality. 

Since rounding occurs in the calculation of node quali- 
ties there is a critical value for this parameter at which 
point node the node quality is not reduced any further. 
If the quality used between TNCs is 255 (even for RS- 
232 value) the critical value for this parameter is 128 
and propagation reaches that in 129 hops. That means 
that if the value for this parameter is less than 128 and 
if qualities of 255 are used for node to node propagation 
that a node would be propagated over a path of nodes 
that was infinitely long. 

The other thing that this means is that if there were 
three nodes that were all neighbors (like in a node stack) 
that if any node that is heard by those three nodes that 
node will stay in the node tables forever, even if it was 
never heard from again. If the quality used between 
TNCs is 64 then the critical value for this parameter is 
0 and the quality is reduced to 0 in 6 hops. 

(Range: 0 - 255) no units 


2. Default path quality - port 0 (radio/HDLC). 

This parameter is the default quality for port 0 which 
is the HDLC or radio port. This number is used to set 
the quality of the path to a newly detected neighbor node 
heard over the radio port. Later the value given to that 
neighbor node is used to process received node quality 
information. 

This number, used as a fraction over 256 (i.e. N+256) 
would be applied to the qualities broadcast by a neigh- 
bor node. If a neighbor node FRED broadcasts infor- 
mation for a distant node GEORGE such that FRED 
knows of GEORGE at quality 120, and if this node (TOM) 
has a route quality of 128 to FRED then this node will 
store GEORGE at 120 x (128/256) = quality 60. 
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Usage: In a system where time to live (Parameter 17) 
is used to determine the number of backbone hops away 
from which this node will be available, route quality to 
all neighbor nodes should be the same on all highest qual- 
ity backbone ports, both RS-232 and radio. 
For backbone nodes used in a hidden transmitter free 
backbone or dedicated point to point backbone (i.e. a 
designed and agreed upon convention between all sta- 
tions using the frequency in the local area) the route 
quality should be set to a number such that the node 
listings will be propagated and the value for parameter 
2 should be set to 0. This makes a violation of the con- 
vention not have any affect on network operation. No- 
tice to all node sysops involved should occur before 
changes are made so that route list changes may be made. 
A convention between participating node owners is nec- 
essary in order to establish a point to point link or hid- 
den transmitter free link. Therefore there is no reason 
not to take precautions against a breach of that conven- 
tion. A point to point link without such an agreement 
is of little value. If such an agreement can't be made 
it's hardly likely that things will stay stable enough to 
make a useful network link. : 
All backbone TheNET TNCs that operate as other than 
agreement supported hidden transmitter free links 
should have all HDLC port 0 route qualities set to a much 
lower value. This kind of radio port is also called a gate- 
way port. In this case the user port at each node site 
that shares the frequency would show at the next site 
across the backbone/gateway but the nodes on either side 
would not be seen or propagated. 
Setting this parameter to 0 does not affect nodes that 
are known via the RS-232 interface (matrix connect), nor 
routes which are already existing or locked in. 
A common error in using TheNET is to assume that 
quality values are affected by or effect the performance 
of communications to and from a neighbor station, ei- 
ther via port 1 or port 0. This is incorrect. Quality values 
are used for node propagation control, that is, how far 
through the network a node will be listed, and to con- 
trol the deterioration of a node listing's lifetime if the 
source of the node is cut off. If a link goes down, qual- 
ity values affect how long it will be before a node list- 
ing vanishes from the network. A shorter time is bet- 
ter as false node listings promote incorrect routing, user 
frustration, and unnecessary network congestion. 
Note: Changing the default path quality will not change 
existing route qualities. This will only affect new routes. 
To change existing routes you can: 
¢ manually use the R command in sysop mode; 
¢ decrease broadcast interval for a short time so that 
the current routes expire; 

¢ disconnect the node from the radio so that current 
routes expire 

(Range: 0 - 255) no units 
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3. Default path quality - port 1 (RS-232). 

This parameter is the default quality for port 0 which 
is the HDLC or radio port. This number is used to set 
the quality of the path to a newly detected neighbor node 
heard over the radio port. Later the value given to that 
neighbor node is used to process received node quality 
information. See parameter # 2 for a complete description 
of quality and default path quality. 

Note: Changing this value will not change existing 
route qualities. This will only affect new routes. To 
change existing routes you can: 
¢ manually use the R command in sysop mode; 
¢ decrease broadcast interval for a short time so that the 

current routes expire; 
¢ disconnect the node from the radio so that current routes 
expire 


(Range: 0 - 255) no units 


4. Obsolescence counter initialization value. 

This value defines how long the node table will keep 
information on another node. Every node listing includes 
an obsolescence count. 

Each time a nodes broadcast is received all nodes that 
are included in the broadcast are updated. The rout- 
ing information for each node, as stored in memory, in- 
cludes the obsolescence for each of three routes. The 
obsolescence count for the route to the broadcasting 
neighbor, for every node in the node broadcast, is up- 
dated to the obsolescence counter initialization value if 
the routing exists for the node in the table and to the 
broadcasting neighbor. If the routing does not exist for 
the node in the table, and if the quality value associated 
with the routing is higher than the lowest of the three 
listings, then the lowest listing will be bumped, the new 
routing will be installed. That routing will then have 
an obsolescence count equal to the initialization value. 

Each time this node makes a nodes broadcast the 
obsolescence values for all stored node listings are dec- 
remented by 1. Each node listing whose obsolescence 
value is decremented from 1 to 0 is removed from the 
routing table. 

(Range: 0 - 255) no units 


5. Obsolescence counter, minimum for 
broadcast. 

This is a filter which determines how old node infor- 
mation can be and yet still be broadcast. 

This sets the limit on the minimum obsolescence value 
associated with each node for it to be included in the nodes 
broadcast. The node doing the broadcasting is always 
included in the broadcast. This value used in concert 
with Obsolescence counter initialization value can be used 
to force a node to only broadcast itself by simply mak- 
ing this parm bigger than the initialization value. This 
is a desirous effect for ports facing nodes which don’t par- 
ticipate in the dedicated link backbone system, on gate- 
ways for instance. 

(Range: 1 - 255) no units 
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6. Broadcast timer interval in seconds. 

A TheNET node TNC has an internal broadcast in- 
terval timer. This value sets that timer. When the timer 
runs out the node decrements the obsolescence counts 
for all of the nodes in it’s nodes table and does a node 
broadcast. The nodes broadcast is a formatted list of 
all nodes in the routing table whose obsolescence counts 
are greater than the minimum to broadcast (see Obso- 
lescence counter, minimum for broadcast) 

Whatever value is set, it should be compatible with 
that of the neighbor nodes. If this node broadcasts more 
frequently than the neighbor node it might forget about 
listings that the neighbors tell it about. This is because 
the obsolescence counts may be decremented past 1 before 
the neighbors rebroadcast. The opposite is true if this 
node doesn’t broadcast often enough. Incompatible node 
broadcast intervals may be overcome by increasing or 
decreasing the Obsolescence counter initialization value. 
(Range: 0 - 65535) in seconds 


7. Link time-out (FRACK). 

This sets the time delay after a packet is sent to a user 
or neighbor node before the node will attempt a retry. 
For double ended hidden transmitter free backbones this 
should be set to a minimum value, 1. For user ports, 
setting this value higher gives priority to those users 
that are most consistent into the node. Higher values 
(8 - 12) should be used on user ports if users are likely 
to be weak. 

(Range: 1- 15) in seconds 


8. Link layer MAXframe. 

This parameter is the same as the MAXframe com- 
mand available in most user TNCs. 

This sets the number of packets, of those that are 
available in memory to send to a user or adjacent node, 
that will be sent in one transmission. In all cases this 
should be set to 1. Setting this to a higher value will 
intermittently allow some users a higher percentage of 
network and user port bandwidth without substantially 
altering total network efficiency.. 

(Range: 1 - 7) in # of packets 


9. Link Layer Maximum retries. 

This value sets the number of times a TheNET node 
will retry on the radio port. This value is the same as 
for a regular user TNC. TheNET nodes default to us- 
ing AX.25 lvl 2. Ifa node to node link retries out then 
the specific destination node (transport destination that 
is) is marked as bad for the one specific neighbor. This 
takes place in the nodes table. See Theory of Operation: 
Routing. Note that no notice of a link failure is sent back 
to either origin or destination nodes in the case of a re- 
try time-out on a backbone link. The only method of fail- 
ure in this case is that of transport layer time-out as 
defined in one of these parameters. 

(Range: 0 - 127) in # of tries. 
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10. Validate callsigns. 

This option allows the sysop to enable or disable callsign 
validation. This affects the C command in the nodes 
command processor. This also affects the valid callsigns 
that may be used to connect fo a node. If this feature 
is enabled a user would not be able to connect to the node 
with the callsign of NOCALL. 

If validate callsigns is turned on the C command in 
the node will only accept valid callsigns and existing node 
names. This feature should be enabled most all nodes 
as this eliminates the delay use user might have to wait 
to find out that he/she specified a node name incorrectly. 
If your gateway port sees KAnodes this feature will need 
to be disabled so that users can connect from this port 
to anode name that won't be listed in the TheNET node. 
(Range: 0 - 1) 0=allow all callsigns; 1=only text strings 
with an imbedded number. 


11. Host Mode connects. 

When a NodeOp has a CRT terminal connected via 
the RS-232 Host Interface, ON (1) will allow users to 
connect to the CRT terminal if the node-op is not actively 
connected to the node at the time. Off (0) prevents us- 
ers from connecting to the CRT terminal. To use this 
feature the user would connect to the node over the ra- 
dio, then type C <return>. If this parameter is set to 1 
the user will get a Connected to message. In normal mul- 
tiport node operation this feature only changes the er- 
ror message the user gets when he tries it. 

(Range: 0 - 1) 0=host mode off, 1=host mode on 


12. Node radio TXD. 

TXDelay in a TheNET node is the same as TXDelay 
in a TNC2. This adjusts the period of time between 
keying the transmitter and when it actually starts send- 
ing data. If this value is too short the receiving station 
will not hear the start of the packet and a failure will 
result. If this value is too long then data throughput 
will be less than optimal. 

User ports should not be shorter than 35 or you will 
exclude stations with slower switching radios from us- 
ing your user port. Backbone ports should be optimized 
to find the absolute lowest value that will work reliably 
with all other radios on its backbone link, then bump 
the number up a few notches so switching delay drift 
doesn’t interfere with reliable Tx/Rx switching. 
(Range: 0 - 255) in 10s of milliseconds. 


13. Broadcast via port. 
This parameter allows the sysop to disable nodes broad- 
casting on one or both ports. The reasons that this might 
be done is to 
e discourage node to node communications on a 
user channel 

¢ reduce clutter on a user channel 

¢ hide the node (if held for a backup route) or 

* inconcert with locking the node in at another 
location this can be used to create a gateway or 
dedicated use link. 


This function does not affect a user's ability to ask for 
and receive Node lists. 
(Range: 0 - 3) 
0 = Broadcasts disabled on ail ports. 
1 = Broadcasts enabled on port 0 (radio) only. 
2 = Broadcasts enabled on port 1 (RS-232) only. 
3 = Broadcasts enabled on both ports 0 and 1 


14, Hidden Node Propagation. 

This causes # nodes (pound or hash) to either be propa- 
gated or not. 

# nodes are usually used for backbone links. The 
maximum number of listed nodes in a TheNET node is 
a setable parameter. If that number can be reduced it 
will free up memory space for other uses. Having # nodes 
propagate is often times not of any value to the network 
users. If that is the case then having he lower you can 
make that setting the more memory space that will be 
available for other things. Also keeping this parameter 
turned off reduces the length of a nodes broadcast if there 
are any # nodes in the local system. 

(Range 0 or 1) 1=# nodes will propagate, 0=# nodes 
will not propagate. 


15. Connect Command Enable. 

If set to 0, connect commands typed after connecting 
to a node are quietly ignored. This prevents stations 
from doing manual L2 connects from a backbone node. 
(Range 0 or 1) 1=connect enabled, 0 = connect dis- 
abled. 


16. Maximum number of nodes in NODES list. 

This parameter sets the number of hidden and vis- 
ible nodes that may be stored in the nodes table for a 
TheNET TNC. This value sets the amount of TNC 
memory used to store the node information. Each en- 
try takes memory space so setting this value much higher 
than you'll likely use is a waste of buffer space that could 
otherwise be used by the node to improve performance 
and increase the number of user connects available. 

Ideally the number of nodes that you'd want to store 
in the nodes table is somewhat less than 100 if only to 
keep the responses from the NODE command short. 
Even a 100 node long NODES response would be sent 
in seven 240 character long packets. Node broadcasts 
(passing routing information) are longer for more nodes 
listed. What is more important is that all of the nodes 
in the node table are available for passing traffic even 
under the most loaded conditions. This is covered un- 
der time-to-live and in other sections of the Notebook. 
(Range: 1 - 400) measured in # of nodes 
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17. Time to live. 

This is the number of hops between user ports that 
your message will travel. For instance, if you have a 
network that looks like this: 


user port 
(note the omni antenna) 


If you were to connect to the FOXTROT user port and 
then do a C ALPHA your message would travel 9 hops. 
If the time to live on FOXTROT, or on ALPHA, was less 
than 9 then you would not get the connect. Eventually 
you'd get a failure with ALPHA which would be caused 
by a transport layer time-out. 

This is the number of node hops that a message from 
this node can go before it is killed. Each message trans- 
mitted through the network by a node has an associated 
time to live. Each time the message is received and re- 
transmitted by any TheNET node the time to live for 
that packet is message is decremented. If the time to 
live reaches 0 the message is thrown out. This param- 
eter sets the time to live start value for each message 
originated by this node. 

If time to live is set too high and if a routing loop oc- 
curs then much network time may be wasted. Addition- 
ally time to live protects the network from long distance 
abuse. If time to live is kept relatively small a poorly 
sysopped node will not cause much damage. Ideally time 
to live would be set to the same number as the maxi- 
mum number of hops that a node will propagate. 
(Range: 0 - 255) measured in # of TNCs 


18. Transport layer time-out. 

Sets the number of seconds that your local user port 
will wait before retrying a packet across the network. 
In this time the destination user port must acknowledge 
the packet and that acknowledgment must make it back 
to the origin user port. If the packet is retried there will 
be a second redundant copy of the message heading 
across the network even if the first copy successfully 
arrived. This value must be set to the maximum amount 
of time that it will take for a packet to travel the num- 
ber of hops as set by time to live (and minimum quality 


with both default path qualities) and for the acknowl- 
edgment to return to the node of origin. 

This parameter has to be reasonably small as this 
determines how long a user will wait when a backbone 
fails or a node is off the air. This number has to be large 
enough, however, that under even the worst loading 
conditions a user will not get disconnected if the links 
do work. The value chosen for this parameter is depen- 
dent on the values chosen for node to node quality and 
minimum quality for auto update. Think of this value 
in terms of number of seconds allowed for each TNC 
traversed in anode to node connect. A value of 200 and 
a maximum number of hops of 7 gives us about 14.5 
seconds per TNC. An end to end acknowledge also has 
to occur in this time period. 

(Range: 5 - 600) measured in seconds. 


19. Maximum transport layer tries. 

Sets the number of copies of a given packet that the 
origin user port will send into the network to the desti- 
nation user port, timed by transport layer time-out, be- 
fore declaring the path disconnected. Originally this 
feature existed so that in a network where all backbones 
were on the same frequency an alternate route might 
be tried on the retries. Unfortunately a single frequency 
network doesn't allow the performance we need so this 
feature must be ignored. 

(Range: 2 - 127) measured in tries. 


20. Transport layer acknowledge time. 

This is the amount of time a port waits before acknowl- 
edging a transport layer packet that was received. 

Faster is better here unless the port will be under con- 
tinuous heavy loading from the same destination node. 
If there are two nodes that are passing information via 
L4 packets, back and forth, and not sharing data with 
any other nodes, setting this value to > 1 will allow ac- 
knowledgment frames to be piggy backed with informa- 
tion frames, thus saving transmission time. The rea- — 
son that this is of little value to us is that most nodes 
pass L4 data with multiple different nodes at the same 
time, not with one single other node. If this value is set 
to it's minimum the performance for random node to node 
communications will be enhanced, at the expense of 
repetitive node to node communications. 
(Range: 1 - 60) measured in seconds. 


21. Transport layer busy delay. 

In the event that a transport layer (L4) circuit can- 
not handle more data (transport layer window size) a 
busy flag is sent back to the originating node. This pa- 
rameter is the number of seconds that the origin node 
waits before retrying a message that was lost due to the 
busy condition. When the busy node clears it also gen- 
erates a packet back to the origin node announcing that 
it is clear. 

(Range: 1 - 1000) measured in seconds. 
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22. Transport layer window size. 

This is the number of unacknowledged packets that 
can be outstanding for a given circuit (each user con- 
nect). If this number is kept small the throughput on 
a very lightly loaded network will be worse than it might 
be with a large window size. If this number is large then 
on a heavily loaded network stations with lots of traf- 
fic would hog the network. 

This number should also be set in concert with the 
Transport Layer Time-out. If a station sends a dozen 
packets, which causes delays, the time-out must not be 
exceeded from the time the last packet leaves the ori- 
gin node to when the last packet arrives at the desti- 
nation node. Setting this parameter to a low number 
reduces this problem. 

(Range: 1 - 127) measured in packets 


23. Congestion control threshold. 

This is the number of packets that can be buffered in 
a user port for a given circuit. 

When a station sends text to a user port the user port 
will try to send the text off to the destination across the 
network. If the network gets slow or if the destination 
can't deliver the text due to problems on the other end 
the local user port will start getting backed up. The 
number of packets that will get stacked at each end is 
the congestion control threshold. 

If this value is set too low, the user station will get a 
choke packet from the user port. The user station will 
send again in FRACK time and will continue in this loop 
until the data can be delivered. This causes unneces- 
sary traffic on the user port channel. On the other hand, 
if the sending station is a server it's input into the net- 
work may be based on network level links in which case 
the choke process is not timed by FRACK but rather is 
timed by Transport Busy Delay. If the server's input 
to the network is via a point to point link but is not a 
network level link then even if the repeat process de- 
scribed above occurs the retry process occurs on a channel 
that won't cause inconvenience to any but the server. 
Since the server is in control of the channel it will not 
delay itself due to this process. Setting the congestion 
control threshold low is only an inconvenience to users. 

If this value is set very high the network will accept 
all of the packets that the origin station sends and will 
save that data until it can be delivered or until the path 
gets disconnected from one end or the other. This would 
be OK for users who don't often type fast enough to get 
ahead of the network. This would be terrible for BBSs 
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when a user connected to a BBS and then read a mes- 
sage. Since the congestion control threshold is set very 
high the network node on the sending BBS's end would 
accept the entire message. The sending BBS would then 
start timing. At a certain time-out the BBS will assume 
that the user has gone away and will disconnect, even 
though the user hasn't even received the entire text he'd 
requested. This problem could be fixed by increasing 
the number of users the BBS can handle at a time and 
then having the BBSs increase the time-out timer. This 
is an expensive solution. In addition the BBSs forward 
traffic to each other through the network. For efficiency's 
sake the BBSs expect a certain turn around time from 
the destination BBS. That time is once again based on 
how long after the message done being accepted by the 
network before the acknowledgment is received. Set- 
ting this value very high would make BBS forwarding 
difficult. 

(Range: 1 - 127) measured in packets. 


Note: Only parameters 1 through 23 are available via 
the PARMS command. Parameters 24 through 33 are 
only available at EPROM burn time. 


24. No-activity timer. 

This is how long a user may stay connected with no 
traffic flowing between the node and his station. 

A higher value allows users to stay connected with no 
traffic flowing. A low value keeps stations from tying 
up available circuits for no reason. 

When choosing a value for a node/port that a user will 
be connecting to, keep in mind that users will be con- 
necting to CROWD nodes and DxClusters which may 
go for extended periods of time without activity. 
(Range: 0 - 65535) measured in seconds. 


25. P-persistence. 

This figure determines the aggressiveness of the TNC’s 
transmit function. A high value of P-persistence will 
cause the TNC to be very aggressive. If there are more 
than 2 TNCs waiting to transmit on a single channel 
and their P-persistence is set incorrectly the data 
throughput will suffer. A formula used to calculate ideal 
P-persistence is Pp = (256/N-1)-1 where N is the num- 
ber of TNCs on the channel that could have data to go 
out at the same time. So, if the channel only has two 
TNCs the P-persist could be set to 255. If the number 
of TNCs is 3 then P-persist could be set to 127. 
(Range: 0 - 255) measured in fractions of time N/256. 
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26. Slot time. 

This is the amount of time the node will want the 
channel to be clear before attempting the P-persistence 
calculation again. 

This value should equal the TXDelay for the node plus 
the worst response delay for other stations on the fre- 
quency. For dedicated point to point links (2 radios on 
a frequency) this value is unimportant as P-persistence 
when set to 255 overrides the value of slot time. As with 
P-persist, this value depends on the type of application. 
P-persist and Slot time work together to set up a ran- 
dom delay determining when the node will key up fol- 
lowing a DCD decision that the channel is clear. This 
is an anti-collision technique. When the node is ready 
to transmit, a number between 0 and 255 is internally 
generated. If the random number is equal or less than 
the value set by P-persist, the node keys immediately 
upon sensing a clear channel. Otherwise the node waits 
for a period of time equal to the slot time and then in- 
ternally generates a new number, etc. A value of 63(+1) 
is 25% of 255(+1) and thus sets the percentage of time 
the node will immediately keyup. Protected trunking 
nodes (those with only one transmitter on their receive 
frequency) would have faster throughput if there were 
no node keyup delay. Setting P-persist to a value of 255 
will accomplish this. 

(Range 0 - 127) measured in 10s of milliseconds. 


27. Link Layer time-out (Resp Time). 

10s of milliseconds between receiving a packet from 
a neighbor node or user before the node will acknowl- 
edge a packet. This is actually the response time in Ms. 
Setting this value too low on a user port will prevent 
some users from being able to access the port as older 
radios and some newer rigs with very slow locking syn- 
thesizers will not recover from transmit fast enough. 
Making this value larger makes the node less aggres- 
sive which might be useful on a crowded frequency. 

This value is dependent on the radios that this TNC 
is talking to. Check this value if problems occur. 
(Range: 0 - 6000) measured in 10s of milliseconds. 


28. Link time-out timer (CHECK). 

This parameter sets an idle link timer. Ifa link is in- 
active for this amount of time a check packet is sent to 
make sure the other end is still there. This value is set 
rather large as making it smaller will start to waste time. 
Making this value 0 will also work but if link no-activ- 
ity time-out is set to a large number a user could turn 
off his station and still be listed as a user on a node for 
the entire duration of the no-activity time-out. 
(Range: 0 - 65535) 
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29. Station ID beacons. 

Configures automatic identification of the node. Le- 
gally all amateur stations need to identify with an au- 
thorized callsign. That means that if someone connects 
to a node using it's nodename it must still identify with 
it's callsign. Since point to point backbone ports are 
always connected to using networking protocol and not 
AX.25 we know that they will always communicate us- 
ing their callsigns. Thus turning on an additional iden- 
tification is unnecessary. On the other hand a user port 
must be identified since it allows users to connect us- 
ing the nodename. By setting this parameter to condi- 
tional the node will only ID when it is in use. By defi- 
nition a Wide coverage user port shares the channel with 
other servers and nodes. Having the ID beaconed ev- 
ery 10 minutes would be greedy of channel time. On 
the other hand a Low coverage user port doesn't share 
the channel and can arbitrate for itself when to make 
it's 10 minute ID transmission. 

(Range: 0 - 2), 0 = no beacons; 1 = legal ID for user 
ports, only; 2 = beacon every 10 minutes 


30. CQ broadcasts. 

This parameter disables or enables the CQ broadcast- 
ing feature. (see User Command List). The CQing user 
still shows up on the USERS list but the CQ unproto 
message is not sent. 

(Range: 0 - 1) 0=no CQ message, 1=CQ message 
enabled. 


31. Full Duplex 

If a point to point link is established using two pairs 
of radios and if both directions can be established at once 
then this parameter can be set to 1. If this is done the 
performance could be really good, especially with short 
packets. 
(Range: 0 - 1) 0O=half duplex, 1=full duplex 


32. Port Direction 

Applies only to nodes equipped with telemetry 
daughter board. Ports are unidirectional for telemetry 
applications. There are 2 ports, labeled Port A and 
Port B. Each port has eight I/O bits, or lines. Ports 
can be designated as: A = I (input, A = O (output), B = 
I (input), B = O (output). 


33. Multipliers 

Applies only to nodes equipped with telemetry daughter 
board. This parameter sets the appropriate scale for 
sensor voltage. 


Ve 
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TheNET v2.10 Review and recommended parameters. 


Wide area 

Parameter Function v2.10 user port 

1 Minimum Quality For Auto Update 50 

2 HDLC Channel Quality 50 

3  RS-232 Channel Quality 203 

4 Obsolescence Count Init Value 3 

5 Obsolescence Count Min For Broadcast 4 

6 Nodes Broadcast Interval (seconds) 900 

7 — FRACK (seconds) 8 

8 MAXframe 1 

9 Link RETRIES 6 

10 Validate Callsigns O=no; 1=yes 0) 

11. Host Mode Connects 0 

12 TxDELAY (10ms intervals) 35 

13. Broadcast Via b0=radio; b1=RS-232 3 

14 Pound Node Propagate O=no; 1=yes 0 

15 Connect Command Enable 0=no; 1=yes 1 

16 Destination List Length 100 

17 Time-to-live Initializer (hops) té 

18 Transport Timeout (seconds) 200 

19 Transport RETRIES 2 

20 Transport ACK Delay (seconds) 1 

21 Transport Busy Delay (seconds) 120 

22 Transport Window Size 2 

23 Congestion Control Threshold 4 

EPROM parameters 

24 No-Activity Timeout (seconds) 7200 

25 P-persistance 64 

26 Slot Time (x 10ms) 35 

27 Link RESPTIME [t2 timeout] (x 10ms) 100 

28 Link T3 Timeout [CHECK] (x 10ms) 65000 

29 Station ID 0O=msgs;1=after; 2=always 1 

30 CQ Broadcasts O=no; 1=yes 1 

31 Heard List Length 20 

32 Full Duplex O=no; 1=yes 0 

Commands Review 

Bye Disconnects from this TheNET node Off 

Connect Connects to another station or another node On 

CQ Sends a unproto packet message and lists the sta- Parms 
tion as calling CQ in the node's Users table. 

Heard Sends back a list of the last 20 stations heard, ifin Routes 
the past 15 minutes. 

Info Sends back the info text, allows sysoptochangeinfo Status 
text. 

Nodes Sends back a list of nodes in the nodes table, allows SYsop 
sysop to make changes to the nodes table. 

Users 
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Point to point 
Local area Backbone with backbone 
user port > 2 nodes between 2 nodes. 
50 50 50 
0 82 0 
203 82 203 
3 3 3 
4 1 1 
900 900 900 
5 3 1 
1 1 1 
10 6 10 
1 1 1 
0 0 0 
35 35 35 
2 3 3 
0 0 0 
1 1 0 
100 100 100 
i 7 if 
200 200 200 
2 2 2 
1 1 1 
120 120 120 
2. 2 Z 
4 4 4 
7200 300 300 
255 64 255 
1 35 1 
30 50 20 
65000 65000 65000 
2 0 0 
1 0 0 
20 20 20 
0 0 0 


Sysop may turn off pin 25 of the SIO 
Sysop may turn on pin 25 of the SIO 


Sends back, or allows sysop modification, of some 
parameters. 


Sends back the routes (neighbor) table, allows sysop 
to change routes table. 


Sends back data on memory usage and current net- 
work status for this TheNET TNC. 


Perform password check to allow modification of 
tables and parameters 


Display current users of this TheNET TNC. 
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Networking Around HTS 


AX.25 is a Carrier Sense Multiple Access system. That's what CSMA stands for. 
CSMA means that each station depends on it's own receiver to determine when it's OK 
to go into transmit mode. In many commercial packet systems which use CSMA type 
protocols it is given that all of the transceivers can hear each other. 


In amateur radio packet that is almost never the case. What that means is that 
sometimes a station can be talking and another will just come onto the frequency and 
start talking. It sort ofsounds like twenty meters on a winter Sunday evening. Usually 
on twenty meters when that happens, an operator who can hear both stations that 
were transmitting will say something like "The frequency is already in use". 


In AX.25 packet what does happen is that the two stations who were talking don't 
get any answer so they try again. Often times the timing can work out so that both 
stations will once again transmit at the same time (collide) and will waste even more 
time. What is worse is that in many areas on two meters there will be more than two 
stations trying to transmit at a time. There may be dozens. This means that the 
number of bad transmissions per successful exchange can be very large. Each time 
there is a bad transmission the stations have to wait a certain amount of time before 
retrying also. This wastes time. 


Most amateur radio packet on two meters is done at 1200 bauds. This means about 
150 characters per second. If there are only two stations in the local area and they can 
only hear each other, and they have reasonably fast radios the number of bytes that 
they can transfer per second is around 80. In a situation with two stations who can't 
hear each other, trying to pass data to another two stations who hear both equally well, 
the rate will probably be closer to 5 bytes per second per station. 80 bytes per second 
is pretty fast for a person to read. 5 is very slow. If the two stations could hear each 
other the rate might be up to 36 bytes per second for two stations. That's assuming that 
they are not both 'greedy'. If they are both 'greedy' it's possible that no data would be 
passed at all! The process by which AX.25 (CSMA) stations jam each other because 
they can't hear each other is called Hidden Transmitter Syndrome or HTS. 


In this illustration we have K2CC 
talking to WZ2B. K1TR is listening but 
is not involved in the conversation. The 
throughput between K2CC and WZ2Bis 
about 80 characters per second. 


In this illustration we have K2CC 
talking to WZ2B. NQIC is talking to 
K1TR. Because K2CC and NQIC can't 
hear each other they frequently go into 


and W2Z2B both get garbage. Through- 
put is drastically reduced. NQ1C and 
K2CC are called Hidden Transmitters 
because they can't hear all of the trans- 
mitters that other stations they talk to 
can. 
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transmit mode at the same time. K1TR | 
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Network Implications of HTS 


100% of theoretical throughput could only be arranged if there was some overriding 
control that made sure that there were never any collisions and that the transmitters 
came onjust at therighttimes. Thisis not possible ifthe only means of synchronization 
is via the CSMA channel and random timers. If all things are arranged as best they 
can be the best performance that can be achieved with a hidden transmitter 
environment is 20% of theoretical throughput. Two notes. 1. Only if all participants 
on the channel are cooperating will this occur and; 2. Only if the participants don't try 
to push the throughput on the channel. If the throughput exceeds a threshold 
(determined by the aggressiveness of the users) then collisions and retries on the 
channel will force the throughput to near 0%. In order to prevent the throughput 
collapse, means of backoff must be implemented. Because backoff is not a feature 
incorporated into most AX.25 based devices the only way to prevent throughput 
collapse is to avoid having hidden transmitters that source data. 


Workable Methods of Avoiding HTS 


For backbones the best method of avoiding HTS is to have no hidden transmitters. 
If there will ever be a situation where two stations were sourcing a data into a 
particular link, even from further down the network, then that link should be a double 
ended point to point link. 


servers, generating data ’ no 
stations receiving data 


Because there is a potential of loading eee 
from more than one source on this 
backbone it should be a point to point 


link, i.e. only two radios on the frequency 
that can hear each other. 


For network access points the same rules apply. If there will be more than one 
source of data cranking out at full speed then there should be dedicated links to each 
source of data. Itis important to note the difference between data generators and data 
receivers. A data receiver isn't a potential part of HTS. You can create a situation 
where there will be a dozen data receivers, hungrily accepting data and only 
generating the briefest of acknowledgment transmissions, on the same frequency. If, 
however, there is even one hidden source of data on the frequency, the data receivers 
will not be able to get even the short acknowledgment through. 


Most packet users spend most of their time receiving data. This is great because 
it fits the model of data receivers only just fine. Even when the average packet user 
is in data generate mode the frequency of packet data transmission is rather low. 
Usually the user is hand typing messages. This fits well within our 20% or less loading 
theory. 


AX.25 in the Network 


So what we have decided is that there are afew different ways that TNCs andCSMA 
are used in the network. There are point to point backbones, low usage hidden 
transmitter free backbones, hidden transmitter free input ports for data generators, 
and user channels for data receivers only. 
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Node Sites and Hardware 


The best place to put a node is where it is most con- 
venient. If it's easy to build a node it is more likely to 
get built. If a node needs to be constructed to serve a 
particular link and only one site will do, then built it 
for that site. There is a lot to be said, however for having 
nodes situated where they can be observed, serviced, and 
played with. 


Higher is not better 


There may be several reasons for putting up a node. 
One of those reasons is to allow a group of packeteers 
to access services or other stations that are available 
through a network of nodes. Perhaps you already have 
a network to link into, or perhaps you have hopes of 
building one. At any rate user access to the network is 
important as the users are the best candidates for cre- 
ating new services and new network installations in the 
future. 


The best user access to a network would be where each 
user has a dedicated point to point link from the network 
node to the user station. This is extravagant to say the 
least. A good compromise would be a low coverage user 
port that serves only a small number of users. The 
limitations and design goals for a user port are that there 
should be no more than twenty stations (ten may be a 
more reasonable figure) on the air simultaneously ac- 
cessing the user port and none of the stations should be 
major sources of data. Very infrequently should the users 
of your user port generate data faster than typing speed. 
Most users spend most of their on air type receiving data 
from BBSs, DxClusters, CROWD nodes or databases so 
this isn't much of a limitation. 


Because your user port can't be allowed to hear any 
other node sites (or servers) your coverage is going to 
have to be strictly controlled. If your node site is on top 
of a high mountain or tower this may be difficult. Use 
of directional arrays or low gain antennas may be re- 
quired. Perhaps an attenuator or tight squelch could 
solve the problem. Keep in mind that your node's user 
port shouldn't be allowed to be heard by the other nodes 
on the frequency either. Sometimes a node site that is 
designed to serve a distant city or long river valley can 
take advantage of tight patterned yagis. Beware of 
reflections off of mountains. If you aim a beam away 
from the mountain you reduce the reflections. Keep an 
open mind and don't use high power. Remember that 
amateur radio spectrum is a limited resource. Use it 
wisely. 
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Node sites in homes have particular advantages. 
Whenever a ham is involved certain characteristics may 
be assumed. One is that if three radios is fun there is 
bound to be five or six in the near future. Putting a three 
port node in a ham house situation is a good way to make 
sure that more expansion occurs. These things are darn 
fun to watch. It is also particularly easy to add local 
computer access to the node with minimum expense. 
This means that a server can be added to the network 
very easily. 


Nodes in commercial sites have advantages as well. 
One of these is that backbone paths can usually be quite 
long. Often commercial sites offer fairly high towers so 
separation between antennas on the same band may be 
achieved. It is quite possible to run as many as a half 
dozen backbone links in the UHF ham band at a single 
site. The way this is done is by running the links in half 
duplex mode. The receive and transmit frequencies may 
be split by as much as fifteen or twenty megahertz. Then 
the links can be set up so that all of the receivers are 
in the high end of the band and all of the transmitters 
are in the low end of the band. So long as the antennas 
are reasonably separated vertically this should be very 
easy. Because your radio's transmitters are about twenty 
megahertz away from the commercial band this may be 
easily approved by the site managers. This is one of the 
more wild ideas for node to node linking. Using 25 watt 
commercial or amateur mobile radios on simplex you 
should be able to get two or three UHF links at the same 
commercial site, given that you can get the antennas and 
coax runs approved. 


One problem associated with commercial sites in some 
metropolitan areas is that the coverage for the user port 
may be higher than desired. The easy solution to this 
problem is to not have a user port at the high node side. 
Perhaps one of the pre-existing servers would house a 
user port. Perhaps you can set up several by using 
dedicated links to each of the local servers in the met- 
ropolitan area and maybe adding a couple of node sites 
just for the sake of having low coverage user ports. If 
your commercial site has good enough coverage of the 
city your cellular user port/nodes can be made using low 
power handy talkies. One watt commercial UHF handy 
talkies can be readily had for less than $100. Used two 
meter ham gear is pretty cheep. A simple UHF antenna, 
a two meter vertical, two feedlines, two TNCs and a power 
supply is all that is required to make a cellular user port. 
Now that you've got all of these simple repeater sites 
located in peoples homes, how long will it be before some 
more backbones start showing up into these sites. Your 
system will expand quickly as the ham radio public 
realizes how much fun it is to play with a real packet 
network. 
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Radios for Nodes 

Radios selected for node use should be capable of heavy 
duty use. The Tx/Rx switch circuitry should be able to 
handle virtually millions of operations without failure. 
This means PIN diode Tx/Rx switching as a first choice 
followed by high quality reed relay switching. Receiver 
front-end filtering should be quite sharp if your node is 
to coexist with other radio services. In that case consider 
using one or two tuned cavities to cut down on front end 
overload and desensitization. If your radio is operating 
on a simplex frequency, the cavities will also aid in re- 
ducing the effects of “white noise” being generated by 
the transmitter. At congested sites, a circulator may 
be required. 


Some amateur class VHF radio’s employing PLL 
frequency synthesizer technology should be avoided. Two 
reasons: PLL settling time between transmit and receive 
is too slow for optimum packet throughput. Consider 
the following table. 


This is a table of maximum throughput in bytes per 
second assuming 230 bytes of data per 256 byte trans- 
mission with a 16 byte acknowledgment, for each popular 
data rate and with different TXDelay settings which 
would be the same on both ends of a data link: 


baud byte Throughput given TXD of 
rate time Oms 4@ms 25@ms 350ms 50Qms 
1200 6.67ms 127 121 99 91 81 
ZayVOT Seo ss’ 2OF 253°" 163° 143° °° 1221 
4800 1.67ms 506 431 241 4199 158 
9600 .833ms 1015 750 316 248 187 
56K .104ms 8131 2124 435 316 225 


Note that the actual TXDelay setting in the TNC 
Parms is in tens of milliseconds. Therefore the 500ms 
values in this chart would be achieved by setting the 
TXDelay to 50; 40ms values would be TXDelay of 4. 


The length of a single byte BYTELENGTH = &/baudrate 
The length of one byte of data, including inefficiencies is 
LOADEDBYTE = [(TXD x 2transmissions) + 
(BYTELENGTH x 272bytes)] / 230 


Throughput per second = 1/ LOADEDBYTE 


This means that the speed of the radio’s transmit to 
receive and receive to transmit switching is vitally im- 
portant. Also, the transmitter may be keyed before 
stabilizing on frequency. This latter situation could cause 
interference to other receivers on different frequencies. 
This may be a serious concern if you choose a commercial 
radio environment for your node. If your candidate radio 
uses PLLs, solicit the manufacturers advice on suitability 
for packet node use. 


In general, retired commercial service FM radios, such 
as the Motorola MICOR and GE MASTR II, or later, 
make excellent node radio choices. The commercial radios 
are designed to operate in moderate to high intensity 
RF environments, are physically rugged, and fairly 
reasonably priced on the used market. These radios 
typically come in a variety of power levels up to 110 watts 
(suitable for long haul dedicated UHF/6m backbone links; 
User ports should generally run less than 25 watts ERP.) 


If this information is daunting to you then please just 
keep it in the back of your mind. Ifyou are running your 
node out of a non-commercial radio site, like your home, 
then you can worry about this after you have your 
multiport node up and running. Using ham radio HTs 
and mobile rigs you can get things going and then swap 
out critical components later. The most important thing 
here is that you get your multiport node up and running 
with dedicated point to point backbones. Then you can 
worry about radio and baud rate improvements. 


TNCs 

MFJ 1270B and PacComm Tiny 2 are the current 
models of the chosen TheNET TNC. Neither TNC needs 
modifications to work with TheNET. However, there 
is a bug with the MFJ1270B in that some models are 
shipped with the RS-232's control lines messed up. The 
general fix for this is to jumper pins 20 and 4 on the RS- 
232 connector for that model. If you use a Tiny 2 you 
can operate at 19.2Kbaud with the HexiPus™. Also the 
HexiPus™ pinout is identical to the Tiny 2 so you can 
use a straight through cable. 
Finally 

Note: Don't compromise on anything. Be as high class 
in your system design as you can and still get results. This 
way your system will expand gracefully. If you compromise 
on your backbones and don't use point to point links you'll 
hurt your network very badly later. Do not, however, wait 
on high tech solutions when low tech solutions will work 
sooner, Many a packet system has been held up until in- 
terest was lost because 9600 baud equipment was going to 
be working soon. Put in the 1200 baud point to point link, 
then upgrade after you have the 9600 baud stuff working. 


Word to the wise: Never tell somebody that they can 
compromise temporarily. Compromise and tempo- 
rarily should never be in the same sentence! 
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TheNET Node Mnemonics 


TheNET nodes incorporate a translation table that 
allows each TheNET TNC to be referred to by a six 
character mnemonic. This mnemonic is called the node 
name. Node names exist for the convenience of the 
human users. When ever the nodes talk to each other 
they use the callsigns, automatically, even if the user 
uses the node name. So, whenever traffic is monitored 
between two nodes on a backbone callsigns will be seen. 


TheNET nodes run in TNC 2s. Thus there is a limit 
to the amount of memory available both for program and 
for data. The number of nodes that can be listed in 
memory is limited. Normally this is limited to 100 nodes. 
A feature of TheNET is that nodes that are used for 
backbone links can be made to not propagate auto- 
matically. That way the only nodes stored in each 
TheNET TNC's routing table are the user connect ports 
or node ports that must be visible for other reasons. The 
way that backbone nodes are set to not propagate is to 
name the node with a "#" character as the first letter 
in the node's name. A second feature of TheNET is that 
when a user requests a nodes list with the NODES 
command the node does not list the # nodes. Thus they 
are called hidden nodes. 


Backbone Ports 

Even though backbone port nodes won't be visible with 
the NODES command they can still be seen by using 
the NODES * command. Also when a ROUTES com- 
mand is done the backbone port nodes will show up. 
Generally the backbone nodes are given full six character 
long identifiers that have the first character as a #. 


One choice for naming # nodes has been to use the 
adjacent node's name as the node name for the backbone 
port. 


Thus in a network that looks like: 


if we looked at the Routes command response from 
FREEDM we might see: 


FREEDM:KB2HPU-1} Routes: 

> 1 #EARTH:KB2HPU-12 203 38 
1 #VENUS:KB2HPU-10 203 37 

> 1 #SATRN:KB2HPU-11 203 29 


FREEDM:KB2HPU 


This makes it pretty clear where one would have to 
connect to look at the actual backbone TNC to go to, say, 
VENUS. The only problem with this is that if you went 
to #VENUS:KB2HPU-10 and did a routes command 
you'd see: 

#VENUS:KB2HPU-10} Routes: 
> 1 #EARTH:KB2HPU-12 203 38 
1 FREEDM:KB2HPU-1 203 37 


> 1 #SATRN:KB2HPU-11 203 29 
> O #FREDM:KA2EIA-13 203 28 ! 


This is somewhat confusing. 


Another method, and perhaps the most useful, is to 
use a site designator for three characters, followed by 
the compass heading, such as #LYNWS, #LYNEA, 
#LYNSO as backbone nodes for the LYNNWD node. 
What you'll see in the routes list at LYNNWD is: 
LYNNWD: KA2DEW-1} Routes: 
> 1 #LYNEA:KA2DEW-12 203 38 

1 #LYNWE:KA2DEW-8 203 37 


> 1 #LYNSO:KA2DEW-11 203 29 
> 1 CROWD: KA2DEW-7 203 1 ! 


What you'll see from the adjacent backbone node in 
Edmonds (west of Lynnwood) is: 
#EDMEA:NONDO-6} Routes 


> 1 EDMOND:NONDO-1 203 1 
0 #LYNWE:KA2DEW-8 203 22 ! 


It is pretty obvious from the routes list at Edmonds 
that we're seeing the LYNNWD node as a route. What's 
more important though is that from the LYNNWD user 
port it is pretty east to figure out which # node to connect 
to if we want to look at the route to the west. 


User Ports 

User ports should be labeled with a town or moun- 
tain, or in bigger cities, the neighborhood. Identifying 
a user port by club, region or airport is not as good. Same 
with using a name that is only known by the locals. The 
purpose for a node name is to identify it's location in the 
network for the outsider. Use the info text to mention 
the sponsor. Clubs are generally not known outside the 
area of it's influence and if it's area of influence is large 
then the location of the 'club’ node is not obvious. 


SATURN:WB7QRP 
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Naming a node by region, like WMA or SNY or COHIO 
is a problem because if the node really does cover an area 
that large then it is probably useless due to hidden 
transmitter problems. Also the very existence of a node 
with such an all encompassing sounding name is that 
other people who might put up a node in the same re- 
gion might feel that they are stepping on toes or that 
redundancy isn't desired. 


Airport identifiers may be sufficient for naming nodes 
as far as locating them on a city by city basis but there 
will no doubt be cases where the airport isn't near the 
city that it is named after, there are many more than 
one node per airport, or there is no airport nearby. Also 
many hams would have a hard time figuring out where 
anode is by it's airport identifier. 


By all means name a node by it's city rather than by 
some cute code that's useless to all but the naming party. 


The user port need not have the frequency in it’s title. 
A node named ALB144 is not as obvious as one named 
ALBANY or ALBNY1. Again the info text, or a map, 
will fulfill the need for a frequency designator. 


Here is a system for compressing a long city name into 
six characters which could also be used for compressing 
into five characters. This method was submitted by 
VE1YZ. VE1YZ gives credit to Boeing Corp. for docu- 
menting this standard for the aircraft industry. 


Names with the desired number of letters or less are 
left alone. 


Names with more than the desired number of 
characters are abbreviated using the following rules 
sequentially until the desired number of letters 
remain. 


¢ Delete double letters. 

¢ Keep the first letter, first vowel and last letter. 
Delete other vowels starting from right to left. 

e Keep the last letter, then delete consonants from 
right to left. 
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LOI oo eae: We . 


Se eh 


Fixes for locations with multi-word name 
¢ Use the first letter of the first word and abbrevi- 
ate the last word using the above rules sequen- 
tially until only the desired number of characters 
remains. 
Examples for six character node names: 
Albany -> ALBANY 
Lake George -> LAKGRE 
Seattle -> SEATLE 


Manchester -> MNCHSR 
Syracuse -> SYRCSE 


It's quite possible to come up with better node names 
than that which this algorithm generates. For instance 
SYRCUS might be better than SYRCSE or LKGORG 
might be better than LAKGRE. It's obvious however 
that this is hands down better than LKG for Lake George 
or MAN for Manchester. 


Specialized Ports 

For dedicated links and server ports, it is a good idea 
to pick a label that fits either the application, or to use 
a abbreviated version of the site’s main user port with 
a number after it. Make sure the info text clearly spells 
out what the port ts for. 


Examples of specialized ports in our network are: 
DXCLUS at UTICA node which is the DxCluster up- 
link, and DXKNOX at KNOX which is near Albany NY 
and serves the YCCC/AARA DxCluster run by K2TR. 
Give consideration to where your label will show on the 
list. This was one of the reasons that BBSxxx was chosen 
for G3BPQ and MSYS BBS ops, so that the BBS’s would 
all be listed in the same part of the nodes table! 


Local Use Ports 

In some node stacks it may be useful to create a vis- 
ible node that only talks to the node owner. One way 
of doing this is to create a node named LOCAL. When 
burning the eprom for LOCAL tell it to turn off nodes 
broadcasts entirely and set the default RS-232 quality 
to 64. Now lock LOCAL in at the user port(s) at your 
node stack at a quality of 50. A more complete description 
of this is in the Putting It All Together section. 


uf 
eee 


Fea OR te 
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Burning EPROMs and Putting It All Together 


EPROMs cost about $5.00 each from mail order places. 
The device you'll want to get is a 27C256-20 32Kx8 
EPROM. That means that it is a 200 nanosecond ac- 
cess time and is CMOS. You can also use any of the 
27256 and 27512 series that is at least as fast as 200ms. 
JDR Microdevices @ 800-538-5000 sells the 27256-200 
for $5.95. The 27C256-200 is $6.95. The difference is 
a minor amount of current consumption and RF noise 
emission. Surplus EPROMs have been seen at flea 
markets for as low as 50¢ in the north west. They've 
been seen for free at other places, The reason that they 
get so cheep is that some companies have rules that 
EPROMs can only be used once. After that they get 
scrapped. 


EPROMs can be reprogrammed hundreds of times, 
supposedly. The very fact that some companies throw 
them out after one burning is a dead givaway that 
something is afoot. Read on. An EPROM is a memory 
device that is programmed with a special tool called a 
PROM burner or EPROM programmer. The appropriate 
one for our purposes can be found from lots of mail order 
houses. JDR Microdevices @ 800-538-5000 sells one for 
PC compatibles that comes as two pieces, a burner and 
a plug in card. I like this one because it uses a high 
quality DB25 to DB25 cable between the two pieces, 
instead of a ribbon cable, programs bigger EPROMs 
which may be useful down the road, and I know that it 
works on a higher speed computer, if you need. Mine 
is running on a 33Mhz 80386 and it's compatible with 
8088 PCs as well. It costs $149.90 and is ordered asa 
MOD-MEP and a MOD-MAC. 


You'll also need a UV eraser (ultraviolet light). This 
is a device that exposes the EPROM's little erase window 
to UV light for a timed interval. The cheaper erasers 
require the user to time them. The erase interval is 
usually not critical. A good eraser will take from 20 
minutes to an hour to erase EPROMs. JDR sells one 
for $39.95 which is a tiny four EPROM eraser called 
DATARASE I. I prefer the $68.50 Logical Devices model 
#QUV-T8/N from Active Electronics @ 206-881-8191 
which erases 15 or so at a time. 


TheNET software is available from land-line BBSs. 
N7GXP's HamShack Data Support System - 406-458- 
9379 in Helena, MT is known to have the latest copies. 
It comes in a.ZIP or .LHA compressed file format. The 
compression programs are also available on the land line 
BBS. You'll need a phone modem to receive this data. 
The other way is to get it in floppy or EPROM format 
from somebody else who has it. If all else fails send a 
message to one of the officers of NAPRA or ask on your 
local BBS. Since I have my JDR catalog out I'll mention 
that they have a PC compatible 2400 baud modem for 
$49. 
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Once you uncompress the software you'll have two 
different ROM versions. One will be called TN209.ROM. 
The other will be TN209B.ROM. The 209 indicates the 
revision number and which will change as new revisions 
come out. Both .ROM versions are usable for backbone 
and user ports. The only difference in the way you set 
the parameters. See the SYSOP's Help Sheet elsewhere 
in this Notebook. You should use the B version of the 
software. The only difference is that the B version shows 
both callsign and node name in the ROUTE response. 


There will also be a program called SET209.EXE. Run 
this program by typing SET209. It will bring up a menu. 
Typea 1. You will be asked to type the name of the ROM 
image you are loading. Type TN209B (or whatever the 
ROM file is called). Do not type the .ROM extension. 
If you do you'll two sequential confusing error messages. 
Now type a 3. This puts you into the editor. Now you 
can change the parameters, node name, callsign and 
password. Most of this is pretty obvious. The password 
option lets you look at the password or change it. Most 
of this is discussed earlier in this Resource Manual. 


To exit the editor use command 0 (zero). Now use a 
4 command to save the file. Again don't type the .ROM 
extension. For file names I use the six character node 
name, using underscores in place of spaces, and followed 
by the ssid of the node. For example: 


node and call file name 
MARS:KA2DEW-12 MARS__12.ROM 
#MARWE:KA2DEW-2 _MARWE02.ROM 
#MAREA:KA2DEW-11 _MAREA11.ROM 


LYNNWD:KA2DEW-14  LYNNWD14.ROM 
You get the idea. 


Now go burn the EPROM. To burn an EPROM the 
way I do it is to copy the .ROM files I'm going to burn 
into the directory with the EPROM burner program. 
Then run EPP-01. You'll need to set up the burner for 
the EPROM type you are using. This is tricky unless 
the chip you are using is in the burner's configuration 
list. You might want to check this list and screen-print 
it for when you go shopping but in practice any EPROM 
can be programmed. It might cost you one or two to figure 
out the appropriate voltages. You may be able to find 
this timing information in spec books or with a call to 
the manufacturar. A error in timing setup probably won't 
hurt the EPROM, it just won't program correctly. Take 
copious notes while you get it worked out. 


The process for burning the EPROM is to blank check 
the EPROM, then load in your data, then program it. 
If the burn fails you need to blank check the next EPROM 
but don't need to load the software again. If you are 
burning a 27256 or 27C256 you need to load the .ROM 
file starting at 0. If you are burning a 27512 you'll need 
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to load the .ROM file at 0 and again at 8000h This way 
we don't care about the state of the A15 connection which 
the 27512 has but the 27256 doesn't. 


After you burn the EPROM you should test it. Turn 
off and then open up a TNC. Remove the battery jumper 
so that the RAM will discharge, remove the old EPROM 
and plug in the new one. Replace the battery jumper 
and power it up. The CON light should come on for about 
2 seconds, then go off. You can plug a terminal into the 
serial port and use host mode to access the TNC. See 
side bar on Use of a RS-232 CRT Terminal. 


After you prove that your TNC is working as a 
TheNET make up a label for the front plate that indi- 
cates the node name, callsign, baud rates you have set 
the TNC to, software rev of TheNET, and today's date. 


If you are putting your TNC at somebody else's site 
or merging yours with other people's equipment you 
might want to write your callsign on the TNC as well. 
On the PacComm units you can write on the on/off switch 
with an indelible marker. It's big enough for the suffix 
of your callsign. 


Don't forget to set the INFO text on your TNC. 


Save the ROM image you are working with on a floppy 
disk so you can reference it later. 


Coupling TNCs together 

TheNET software has two different modes of com- 
munications over it's RS-232 port. It can talk in ASCII, 
as in to a CRT terminal, or it can talk in TheNETese, 
as in to another TNC or PC compatible. In order to use 
a PC compatible you'll need to be running one of several 
programs on the PC compatible that understands 
TheNETese. NOS, MSYS and G8BPQ are all capable 
of this. The switch to make the RS-232 port talk one 
or'the other is a jumper on the RS-232 connector on the 
TNC. On the PacComm Tiny 2 the jumper is between 
pins 5 and 9. On the MFJ 1270B the jumper is between 
pins 10 and 23. The wiring instructions for the 
HexiPus™ include this information. If you use the 
HexiPus™ you can get DB9 to DB9 cables to hook the 
HexiPus™ directly to the PacComm Tiny 2 because the 
HexiPus™ wiring includes the jumper between 5 and 
9. JDR Microdevices 800-538-5000 has both connectors 
and DB9 to DB9 cables for reasonable prices. CBL-MNT- 
9, monitor extension cable DBY to DB9Y is $4.95. DB09S, 
male solder cup DB9 is 45¢. DBO9P is the female at 45¢. 
Their price on connectors is something like 1/4th of Radio 
Shack prices. 


Note that in some older TAPR2 compatible TNCs and 
MFJ 1270 TNCs you'll need to run a jumper inside the 
TNC box (under the PC board) between the ground side 
of JMP9 to pin 23 on the DB25. The ground side of JMP 
9, which is a six pin jumper, is the side of the set of pins 
that has three pins connected together. This should be 
on the front side of that jumper set. 
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Some of this information is from the NEDA Hexipus 
document v1.3 NEDA is Box 563 Manchester NH 03105. 


If you are putting up a 2 port node or just want to 
test a pair of TheNET TNCs on the bench you can as- 
semble a 2 port cable without diodes. The connections 
are as follows: 


For MFJ 1270B 
Make these connections 
1st DB25 2nd DB25 
DDS octane sha: pin 2 
pin 46020. se dacte hes. pin 5 
PLE De ee esccste east. pin 4&20 
pin 10&23 


You should have 9 pins in use on each connector. 


For PacComm Tiny 2 
Make these connections 


1st DBO 2nd DB9 
PLO ees usar ie pin 3 
Dil oer iat a .csnc. pin 2 
PUD GGcDeeetee ces pin 5&9 
PUT CAL e 6 kaceenshees pin 8 
PUY Be rete cite cen pin 7 


You should have 6 pins in use on each connector. 


If you are using more than two TNCs in your node 
stack you will need a HexiPus™ or equivalent. Even 
if you are only making a two port node it might be use- 
ful to acquire a HexiPus™ to simplify construction and 
to add expansion ability. 


Note: The TheNET software determines that the RS232 
port is being used to talk to another TheNET node by 
looking at an input line on it’s DB connector. For Tiny 
2 TNCs pin 9 jumpered to pin 5 selects TheNET. For 
MEF Js it’s pin 10 jumpered to pin 23. If these pins are 
not jumpered the TheNET software assumes that the port 
is being used to talk to a CRT terminal. 
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Constructing a HexiPus™ is very easy. The DB9 
connectors on the HexiPus™ are the same connectors 
as on a Tiny 2. You can even use video extension cables 
for HexiPus™ to Node connection cables. The cable 
wiring information for the HexiPus™ is in a side bar 
on this page. 


Good mods for node building 

There are two good modifications you'll want to do to 
each of your TheNET TNCs. The first makes the STA 
and CON LEDs indicate communications on the 
HexiPus™. The second makes the power LED double 
as a node-in-use indicator. 


Wink and Blink Mod 

This modification is very useful in that it is best way 
to detect and diagnose cabling problems on the RS-232 
side of your node stack. Once you have done this mod 
the STA light indicates that the TNC is getting a busy 
signal from the matrix. The CON light indicates that 
the TNC is asserting busy on the matrix. 


Lift pins 16 and 25 on the SIO. (You'll have to pull 
the chip out of the socket, bend the pins out straight and 
plug it back in). Now, on the bottom of the PC board, 
put a jumper between pin 16 of the SIO socket and 23 
of the SIO socket and another between pin 25 of the SIO 
socket and pin 24 of the SIO socket. Do these jumpers 
on the bottom of the board. 


Meke sure you are using the SIO, 
not the 460. It's the chip closer 
to the modem ciscamect sockex 


What this does is make the STA light indicate RS- 
232 Receive activity and the CON light indicate RS-232 
Transmit. If you are using the 3 way wireline to tie two 
or three TheNET clusters together and if you do the STA/ 
CON modification to each TheNET TNC in the 3 way 
then you'll have a decent diagnostic tool to show you all 
of the activity on any of your TheNET ports. 


Wink 'n Blink mod ere iN yer: 

Jumper pins 24 and 25 me ab 

and pins 23 and 16. = a: 

Unplug the SIO and lift pi ia 

pins 16 and 25. — — 

wz 28440 om 

= Z80SIO om 

View of solder side of PC board ler ash 
PIN 25 ----> AED 


PIN 21 ----> mm 


A 
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Node in-use LED mod for Tiny 2 

TheNET Plus allows that the STA LED indicates that 
the node is in use by someone connecting to another node. 
Since the Wink and Blink Mod makes use of the STA 
LED we don't get to take advantage of that feature. What 
we can do, however, is use an extra inverter in the Tiny 
2 to make the PWR LED go off when someone is using 
the node to connect to another node. The mod is pretty 
easy. 


After making the Wink and Blink mod, lift (by 
desoldering) the right hand lead of resistor R13. It's the 
end right next to the power button. Unplug the socketed 
74HC14 marked U6 and lift pins 12 and 13. Be careful 
lifting the pins as they will break off if you bend them 
straight up from the chip end and if you only bend them 
straight out they will intercept the power switch. 
Wirewrap or solder a wire from the lifted end of R13 to 
pin 12 of the 74HC14. Now wirewrap, or solder, from 
pin 13 of the 74HC14 to pin 16 of the SIO (pin previ- 
ously lifted for the wink-n-blink mod). 


Now when you power up your TNC the CON LED will 
light immediately, then go off followed immediately by 
the PWR LED coming on. Shortly thereafter the CON 
LED will flash indicating that a node's broadcast is oc- 
curring. 

After you have modified two of the TNCs you should 
hook them up to a matrix and power them both on. When 
the power is cycled on one of the TNCs you should see 
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the STA LED flash on the other TNC, reflect- 
ing when the cycled TNC starts up and when 
it does it's nodes broadcast. 


How to test the node stack 

You will need some way to further test your 
node stack. There are four ways to do this. You 
can use another TNC, radio and terminal to 
talk to one of your TheNET TNCs. You could 
wire the audio from the other TNC to one of 
your TheNET TNCs. You could use a G8BPQ, 
MSYS or NOS program on a PC wired into the 
matrix appropriately, or you could build a 
wireline user port for a permanent debugging 
and operating position or as a portable diag- 
nostics tool. I strongly recommend the wire- 
line link. 
Wireline link user port 

This requires two TNCs. One of the TNCs 
will run TheNET software and the other will 
be anormal user TNC. The result of this mod 
will be that you'll have a user TNC that has a 
high speed secure connection into your node 
stack. The only requirement of the user TNC 
is that it must have a TTL modem disconnect 
header. I'll describe the hookup for a PactComm 
Tiny 2 and leave it to you to figure out the 
others. One note is that on some TAPR 2 
compatible TNCs (MFJ 1270B) the state of the 
DCD input is inverted so you'll be able to leave 
out the inverter chip used for the Tiny 2. 


1 Setradio port baud rates on the two TNCs 
to the highest that they will both go. 


One of the TNCs will be designated userTNC 
and one will be designated LOCAL. 


2 set LOCAL's baud rate the same as you 
will be using for your diode matrix com- 
munications. 


3 setuserI'NC's baud rate for whatever you 
will be using to talk to your terminal or 
computer. Higher is better for this. 


4 burn a TheNET EPROM for node with 
your callsign and some ssid and the 
nodename of LOCAL. Make the password 
something that is easy to do, like 
123456789012345.... or. AAAAABBBBB. 
This node is one you'll be sysopping a lot. 
See the side bar for parameters to use for 
this TNC 


5 dothe wink-n-blink and node-in-use mods 
for LOCAL. 


6 install the EPROM into LOCAL. 


7 apply power to LOCAL and make sure 
that it comes up when you turn it on. 
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Ifyou are using a PC based TheNET compatible node make 
sure that you set the windowsize and timeout timers to com- 
ply with the parameters for a user port as shown in the Pa- 
rameters section of this document. The reason that we can 
get away with a Transport Timeout of only 5 seconds for the 
LOCAL node is that the LOCAL node's time-to-live is set to 
1 so transport level communications cannot occur between 
LOCAL and another node beyond 1 hop. Therefor there won't 
be any radio hops on that path. 5 seconds is plenty of time 
for one RS-232 matrix hop. 
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8 hook up a radio and see that it makes the node 
broadcast over the air and that the DCD LED indi- 
cates squelch open. 

9 plug in a terminal to the back of LOCAL and see 
that the RS-232 works. 

10 disconnect power from LOCAL. 

11 test userI'NC with your terminal and see that it is 
functional. 

12 set userI'NC to your callsign. 

13 disconnect power from userf'NC. 

14 disassemble LOCAL and userTNC. 

15 obtain a 5 conductor wire (or 5 wires) about 24 
inches long. 

Steps for PacComm 

1 move the DCD select jumper to external DCD. 

2 acquire a 74HC04, or 74HC14 Hex inverter IC 
(74LS04 is OK substitute). Radio Shack part #276- 
1802 looks right. Make sure it's a LS or HC part 
though. You never know from those guys. 

3 bend and break pins 5 and 6 from the inverter IC. 

4 bend and break pins 8 through 13 from the inverter 
IC. 

5 bend pins 1 through 4 straight out from the inverter. 

6 place the inverter over U11 in userT'NC and solder 
pins 7 and 14 of the inverter to U11. 

7 on the bottom of the board for userT'NC cut the 
jumper on the modem disconnected header from Pin 
17 to pin 18. 

8 onthe bottom of the board for LOCAL cut the jumper 


10 


11 


12 


13 


14 


15 


on the modem disconnected header from Pin 17 to 
pin 18. 


in userI'NC solder a wire from pin 1 of the inverter 
to pin 5 of the modem disconnect header. 


in userT'NC solder a wire from pin 4 of the inverter 
to pin 5 of user!'NC's 5 pin DIN. the pin #s for the 
DIN are on the back plate of the TNC. 


loop the five conductor 24" jumper through the TTL 
COMPUTER hole in the back plates of the two 
TNCs. Make sure the plates are oriented such that 
they can be attached to the TNC, i.e. through the 
plastic bezel, then through the back of LOCAL, then 
through the back of userIT'NC, then the plastic be- 
zel. 

using the five conductor 24" jumper connect pin 2 
of the inverter to pin 5 of LOCAL's 5 pin DIN. 
solder a second conductor from pin 3 of the inverter 
to pin 5 of LOCAL's modem disconnect header. 
solder a third conductor from pin 15 of userTNC's 
modem disconnect header to pin 15 of LOCAL's 
modem disconnect header. 

solder a fourth conductor from pin 17 of userI'NC's 
modem disconnect header to pin 19 of LOCAL's 
modem disconnect header. 
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16 solder the last conductor from pin 19 of userTNC's 


modem disconnect header to pin 17 of LOCAL's 
modem disconnect header. 


Steps for MF J 1270B 


1 


Either unplug the mode disconnect header jumper 
between pin 17 and pin 18, or on the bottom of the 
board for user['NC cut the jumper on the modem 
disconnected header from pin 17 to pin 18. 


repeat previous step for LOCAL TNC. 
loop the five conductor 24" jumper through the hole 
in the back plates of the two TNCs. 


solder one wire from pin 5 of the modem disconnect 
header in userTNC to pin 5 of LOCAL's DIN radio 
connector. 

solder one wire from pin 5 of the modem disconnect 
header in LOCAL TNC to pin 5 of user TNC'’s DIN 
radio connector. 

solder a second conductor from pin 3 of the inverter 
to pin 5 of LOCAL's modem disconnect header. 
solder a third conductor from pin 15 of userT'NC's 
modem disconnect header to pin 15 of LOCAL's 
modem disconnect header. 

solder a fourth conductor from pin 17 of userTNC's 
modem disconnect header to pin 19 of LOCAL's 
modem disconnect header. 

solder the last conductor from pin 19 of userT'NC's 
modem disconnect header to pin 17 of LOCAL's 
modem disconnect header. 


Finishing steps 


1 


(Se) 


clean and inspect the two TNCs making sure that 
there are no shorts, wire strippings or solder blobs. 
Check that you haven't disturbed any other mods. 


lay the two TNCs on an insulated surface. 
apply power to LOCAL and turn it on. 


if you have made the wink-n-blink and node-in-use 
mods the CON light should go on, then off, followed 
by the PWR light coming on. No other LEDs should 
be lit and PWR light should remain on. There will 
be no node broadcast flashes. 


apply power to userI'NC and turn it on. As usual 
the STA and CON lights should go on and then off, 
leaving the power LED lit. The DCD and PTT lights 
should be off. 


Now plug your terminal into userT'NC. 
do a connect to LOCAL 


observe the PTT and DCD lights on the two TNCs. 
When the PTT light is lit the DCD light should be 
lit on the other TNC. They should toggle back and 
forth rapidly during use. 


hit a few carriage returns and observe the light 
patterns. The STA light on userI'NC should not 
stay on for very long. 
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9 Now go back to command mode on userI'NC and 
set TXDelay to 1, DWait to 0, RESPTIME to 0. That 
should make things nice and fast. 


10 sysop LOCAL and see that your password works. 
Set LOCAL's info text to something like this: 

LOCAL:KA2DEW-10} } 

wire link TNC connected to KA2DEW's user station 

C KA2DEW-4 to get Tadd's mail drop and more information 

then do L to list messages 

Notes on the use of LOCAL: 

After you get through the testing stage listed below, 
and if LOCAL will be a permanent part of your node 
stack, you'll want to go to each of your TheNET TNCs 
and lock in LOCAL as a node. LOCAL will not broadcast 
if the parameters were set as in the side bar because if 
it did, each time you brought local with you to test a site, 
LOCAL would show up all over the network. Instead 
it is left to the node op to lock in LOCAL using the sysop's 
N command. When you do lock it in you should set it 
to a quality of 50 and a lifetime of 0 (permanent). That 
way it will only be visible at your node stack. Other node 
ops may also have a LOCAL node. You really only need 
to lock in LOCAL at your user ports. 


Testing TNCs across the matrix 

In order to test the TNCs across the matrix you'll need 
to have a the ability to do a connect from a TNC that 
your terminal can plug into, to one of the TNCs on the 
matrix, or you'll need one of the PC based TNCs as 
mentioned above. 


hook the matrix up to two TheNET TNCs. 
power up one of the TNCs. 
Note the nodes broadcast flicker of the STA light. 
power up the other TheNET TNC. 
this time when the STA light is lit the other TNC's 
CON light should also light up. 
4  nowpower cycle the first TNC. Note that the CON 
lights and STA lights track in this case as well. 
5 using whatever means you are using, connect to 
one of the TNCs. 
6 doa NODE * command and a ROUTE command. 
Note that the other TNC shows. 
7 connect to the other TNC 
8 youshould see activity on the STA and CON lights. 
9 the PWR light should go out on both TNCs. 
10 DoaNODE* and ROUTE command and note that 
the other TNC shows. 
11 your system works. Have a beer. 
CROWD nodes 
A CROWD node is an integral part of any network. 
All networks should have one every four or so hops. It 
is important, however, that there aren't too many of them. 
If there are too many CROWDs there will be too few users 
to every create a synergy. This is: If there is only one 
person on a CROWD he gets board and goes away. If 
there are many CROWDs this situation will usually be 
the case. So, if you own one of many CROWDs and you 


WOnwhN Fe 


find that there isn't very much activity on it you might 
want to either turn off your CROWD or make it known 
that yours is a backup. Choose the CROWD that has 
the best connectivity to the network as a whole and leave 
that one on. 


CROWDs don't work if there isn't adequate connec- 
tivity. It takes several good low coverage use ports to 
keep a CROWD adequately occupied to be fun. Make 
sure that you have point to point links working well before 
you put on a CROWD or you'll burn out your potential 
usership before it gets rolling. Focus your attention on 
getting multiple nodes connected via high quality links 
before you get the CROWD going. 


How to make a CROWD go 

CROWD is a software product of NORD><LINK. It 
is part of the TheNET set and runs as software in a TAPR 
2 compatible TNC or Tiny 2. The CROWD is operated 
as one TNC of a node stack, connected via a matrix. It 
can actually be used via the radio port in the TNC as 
well although this is rarely done. 


First you have to find the CROWD software. It is 
available on the same telephone BBSs that you can get 
TheNET at. It's usually called CONVERS or something 
similar. 


To configure the CROWD chip to your call and node 
name you can use SETNET.EXE which is the original 
TheNET configuration program. You cannot use SET210 
or SET208. They are not compatible. You could also 
use the binary editor included with most prom burners 
but it's not easy. Norton disk edit works also, but not 
easily. The parameters you'll want to use for CROWD 
are shown here in a side bar. 


A note about CROWD coverage: If your CROWD shows 
up on a node that already has a CROWD you will need 
to make use of the N and R commands to reduce it’s 
coverage by modifying the route quality or node qual- 
ity. You can make good use of the R 2 command to 
specifically limit your CROWD or somebody else's 
CROWD from crossing the backbones in and out of your 
node stack. 


In summary 

If you can think of anything that I've left out in re- 
gards to getting a node started please drop a packet to 
NAPRA @ NONDO, ATTN: Notebook Editor. 


One rule to keep in mind when making a node or 
network, don't compromise. Don't do anything tempo- 
rarily. Assume that any temporary fix that you are con- 
templating is permanent. If you compromise on some- 
thing once and loose a bit of potential performance, you 
will send a message to the users of your system and to 
other potential system builders that this is what they 
can expect and that this is OK. Wrong! 


Make sure you have fun and spread the word. 73! 
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Common Problems 


¢°eThe TNC seems to be operating at an extremely 
low baud rate or it takes forever to transmit. 


The problem may be in the baud rate generator or the 
baud rate switch. Check the jumpers if it's a PacComm. 
If it's an MFJ it may be a broken switch or the switch 
may be set to an improper value. 


ee elf the node is doing funny things like: 


¢ only working over the radio or only working over 
RS-232 
not responding at all 
using the wrong callsign or node name 
transmitting all the time 
not handling the LEDs right 
disconnecting everybody once in a while 
never nodes broadcasting or ignoring incoming 
broadcasts entirely 
Try sysopping the node and using RESET or if you 
have local access you can turn off the TNC, remove the 
battery jumper for more than 30 seconds, replace the 
jumper and then turn the TNC back on. 


eee e e 


¢ elf your new node stack doesn’t allow you to connect 
across the matrix, make sure that you have waited long 
enough for nodes broadcasts to work. The nodes 
broadcasts over the matrix happen at the same time they 
do over the radio. Just because the TNCs are stacked 
they don’t necessarily know about each other. It is 
possible using the Sysop:NODE command to lock in each 
port in your node stack to each other port so they begin 
communications immediately. This is a good way to get 
used to doing sysop commands. 


Also if you are using TheNET 2.09 or later you can 
reboot the TNCs. Turn off one, turn it back on and wait 
5 seconds. Now do it to the next one. That will make 
sure that all of the TNCs have node listings for each other. 


¢¢°You've changed the parameters so that the default 
route quality is 200 but the routes are still at the old 
value. 


The route qualities are set by the parms when the route 
first comes into existence. If you want the route qual- 
ity to change you must either change them manually 
using the sysop route command or by making the routes 
go away and then come back. This can be done by in- 
creasing the nodes broadcast rate (parameter 6) tem- 
porarily or by disconnecting the radio or matrix for several 
nodes broadcast intervals. 
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When a neighbor node is first heard the route qual- 
ity is set based on the parameters. Simply changing the 
parameters does not change the route quality. However, 
if you change a route quality to a neighbor node, the nodes 
sourced from that neighbor node will change in value 
as soon as the next nodes broadcast is heard from that 
neighbor. 


e ¢°Traffic across the node stack seems to get delayed 
by several seconds even though the backbones in and 
out are not particularly busy 


This may be caused by incorrect wiring of the matrix, 
connectors to the TNCs or problems with the TNCs 
themselves. Make sure that the TNCs respond correctly. 
If you haven't done the wink and blink mod you should 
do this now. What may be happening is that the CTS 
signal isn't getting asserted onto the diode matrix when 
a TNC goes to send data over the matrix. The other TNCs 
may be transmitting at the same time. 


¢eeQOne or more nodes show on your NODE list but 
you can't connect to it. 


This may be caused by the quality levels being set too 
high on one of the intervening nodes for the time-to-live 
settings on one of the two end nodes. This is common 
when interfaces between non-compliant networks are 
incorrectly constructed. Ideally a gateway would be set 
up which would be used as a stepping point between the 
networks. If no such gateway exists and the nodes are 
allowed to propagate across the interface, such non- 
connectibility problems are bound to happen. Your best 
bet is to find that interface and step across it manually. 


It could also be caused by the quality levels being 
uneven going on the reverse path back to your node from 
the destination node. Normally this second problem is 
fixed by what is called slime-trailing. Slime trails don't 
work if one of the TNCs along the way has a full NODE 
list. 

¢eelf you have any other problems or figure out a 
problem for yourselves make sure you send a message 
about this to NAPRA @ NONDO subj: ATTN. tech docu- 
mentation. 
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TheNET X-1 
Software 
Reference 


TheNET . 
Portable. Compatible. 
for TheNET Amateur Packet Radio Networking Public Domain. 
NORD><LINK 

seta tet a reeab TheNET software is public domain 

1s version O e resource Manual edl yy é 
Tadd Torborg, KA2DEW and ONLY for non commercial use. 
Pr ; d d ae ED TheNET software by 

ogramming and source documentation by Lave, Hans Georg Giese DF2AU & NORD><LINK 
G8KBB and by Dave, GKBB 
Tadd merged all of the documents supplied in the X1- The authors deny any 
G zip file, titled each section which was formerly it's eee aes for the 
own document and added the ALIAS command to the product or its use: 


Quick Reference. 
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TheNET X-1 Reference 


This document and the software it describes are fairly 
new to me. I've seen several copies of X1-G on the air. 
Isaw some bugs. X1-H came out shortly thereafter and 
fixed the bug that I was worried about, that of not per- 
forming correctly when talked to by a G8BPQ node. 


This document is a 99% unedited copy of what came 


with the X1-G software when I downloaded it from 
W3IWI's Tomcat BBS. X1-H didn't change much and 
I'd already gotten this to the stage you see it by then. 
I'd like you to read the TheNET 2.10 resource manual 
whether you decide to use this or not. 


—Tadd, editor 


Introducing TheNet X-1 


This short note summarises the new version of TheNet 
X-series. 


This release extends TheNet X-1F by adding an IP 
router, the ability to remotely set the node alias and the 
ability to listen for 3 additional aliases & automatically 
invoke the BBS, HOST or DXcluster commands on up- 
link. Additional node broadcast controls exist in the form 
of selective port control over ‘hash’ node broadcasting. 
QUIT is introduced as an alias for BYE, and a UI com- 
mand allows arbitrary UI frames to be sent for use in, 
for example MAIL notifications. In the routes list, call- 
signs may optionally be shown as alias:callsign. 


A menu driven windowing patch utility with context 
sensitive help is also included. 


The previous releases introduced the following : 


Access control list capabilities, Multi-user conferencing 
(the ‘TALK command), A CWID keyer, Better SYSOP 
authentication, MHeard list showing callsigns, packets 
heard & time since last heard, A Closedown command 
to remotely shut the node down A DXCluster command 
that operates like the BBS & Host commands A Btext 
command to set the node’s beacon text message The 
ability to enable or disable any command, Improved 
command prompting with only valid commands shown, 
Additional control over system reset, KISS as an alter- 
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native to the crosslink protocol, Hardware handshake 
controlled host mode operation, MODE command for 
configuring additional parameters, BBS command to auto 
connect to a remote BBS, HOST command to auto con- 
nect to another BBS or Host, BYE command to discon- 
nect, STATS command to display internal statistics, 
MANAGER command for system manager access, AU- 
DIT command to set system audit levels, Bug fixes (e.g. 
info messages too long) Changes to the NODES com- 
mand, An improved nodes broadcast algorithm for the 
crosslink port Split port nodes broadcast intervals, Ability 
to enable & disable nodes broadcasts selectively on each 
port. CQ apologises nicely if disabled. Most Escape 
commands have been replaced with MODE parameters. 
Beacon messages may be digi’?d CALIBRATE command 
for remote checking of Tx deviation LINKS command 
to show current level 2 links Configuration of the bea- 
con period Auto routing of ‘connect’ to either BBS, 
DXCluster or HOST Remote dump of entire neighbour 
lists for all nodes 


If you are interested, read the OVERVIEW documents, 
or drop me a line. 


Dave G8KBB @ GB7MXM 
TheNet X-1G 
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Distribution Floppy Disk 


This disk contains the distribution version of TheNet 
X-1G. 


1. Hardware Requirements 

The software runs in a Z80 based TNC2 or similar 
clone such as the BSX2. It is installed as described in 
the bankswitch mods file, but essentially all it needs is 
a single piece of wire from pin 8 of the modem discon- 
nect header to pin 1 of the eprom. 


The Eprom needed is a 27512, rather than the 27256 
of anormal TNC2. Pin 1 of the eprom is bent out from 
the socket and connected as described above. 


2. Installing over TheNet X previous versions 

If you are replacing a previous rom with thenet in it, 
be sure to do a coldstart (you may need to remove the 
battery link to force this) 


3. Files 
The files on this disk are: 
read.me This file 


thenetl.xig Part 1 of the code 

thenet2.xlg part 2 of the code 

configur.xlg Installation guide 

userguid.xlg A user’s guide to the node 

overview.xlg The sysop’s manual 

patch.exe A windowing driven patcher for thenet?.xlg 
quickref.xlg A handy quick reference guide 

intel.exe An Intel hex file dump utility 

intel.c The source of the above 

motorola.exe A Motorola S1 type file dumper 

motorola.c The source of the above 

bankswit.mod Information on the hardware bankswitching 
intro.xlg The brief release note 


4, Using it with a TCP/IP system 

One of the reasons for the inclusion of the IP router 
was to help the development of IP networks. This is in 
two different ways : 


1. It allows a IP station that does not run 24 hours 
to run an JP router for the others in the area without 
leaving the PC running 


2. It allows existing nodes to double as IP routers. 


In scenario 1, where a station runs a TNC2 clone with 
a KISS rom or similar, this software may be used in- 
stead of the KISS rom. It should be configured to run 
KISS, Selective Copy on the RS232 port. 
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5. The other version 

The version that includes the HIGH and LOW com- 
mands is not included here. ANyone who specifically 
needs it, drop me a line. The reason for this is due to 
the more complex bankswitching that it needs - I do not 
think anyone is still using it. 


6. Problems 

As far as I know, the only funny is over the reset com- 
mand. For reasons I cannot understand it sometimes 
locks up if asked to warmstart with the reset command. 
Coldstart seems OK as does warmstart on power on. I 
have included complex integrity checking to try to help 
but it is still there!. 


One common problem. If your node appears to ‘lose’ 
nodes, look very carefully at the rates of node broadcasts 
and the setting of the algorithm control. The RS232 rate 
should be faster than the radio rate or it should be set 
to zero, and the alternative algorithm should only be 
enabled on the RS232 port if at all. Try switching it off 
to see if that helps. 


The patcher has been altered. The code now comes 
as two parts and the patcher patches both at the same 
time. It needs & expects to be able to access both parts. 


73’s 

Dave G8KBB @ GB7MXM..#36.GBR.EU [44.131.16.31] 
g8kbb.ampr.org 

7, Rowanhayes Close Ipswich IP2 9SX England 

Tel 0473 682266 +44 473 682266 
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Configuration instructions 


1. Introduction 

This document describes the build process for creat- 
ing a rom image for TheNet X-1G. This process differs 
from the previous versions of TheNet-X in that it is de- 
livered as two files rather than three. This is in response 
to a number of requests for a simpler process. In addi- 
tion the patcher has been considerably changed and 
utilities for hex conversion are included. 


2. Files. 


The ROM image comes as two files, 
THENET1.X1G 
THENET2.X1G 


These two files are loaded into memory as described 
below. Before loading them however, both should be 
configured as described in section 3. 


In addition, the following files are also provided : 
PATCH.EXE 
INTEL.EXE 
MOTOROLA.EXE 
INTEL.C 
MOTOROLA.C 


PATCH.EXE is the windowing patch utility for the 
rom images. INTEL.EXE and MOTOROLA.EXE are 
utilities that are designed to convert binary files into hex 
notation, in the Intel Intellec and Motorola S formats. 
The rom image consists of two halves, one for the lower 
half of a512K EPROM, and one for the upper half. The 
files are loaded as shown : 

FILENAME Load starting at hex 


THENET1.X1G 0000 
THENET2.X1G 8000 


No information on how to load the files into a program- 
mer is presented as all are different. Typical scenarios 
are however given in section 5. 


3. Configuration 

Each of the two halves of the ROM image contains 
two different parts, a common set of drivers and inter- 
rupt routines and part of the functionality of the node. 
Part 1 contains the level 2, 3 and 4 software. Part 2 
contains the switch. Each must be patched in an iden- 
tical way to reflect the desired operation as each part 
contains an identical section at the start of the file for 
configuration data. This patching may be done manu- 
ally or it may be done with the patcher. 


The first part of the rom images is identical to TheNet 
1.01 in its configuration. These parameters are followed 
by additional ones for the extended version as shown : 


Addr Size Description 
003B 6 bytesof callsign of the node 
0041 byte SSID of the node callsign 


0042 6 bytesalias of the node 

004A word Minimum quality for auto-update 

004C word HDLC default route quality 

004E word RS232 default route quality 

0050 word Obsolescence count init value 

0052 word Obsolescence count minimum for broadcast 
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0054 word 
0056 word 
0058 word 
005A word 
005E word 
0060 word 
0062 word 
0064 word 
0066 word 
0068 word 
006A word 
006C word 
OO6E word 
0070 word 
0072 word 
0074 word 
0076 word 
0078 word 
007A word 
007C byte 
007D byte 


Nodes broadcast interval, in seconds 

Level 3 Time-to-live initializer, in hops 
Transport timeout, in seconds 

Transport retries, in seconds 

Transport acknowledge delay, in seconds 
Transport window size, in frames 

Number of buffered frames per connection 
No-Activity timeout, in seconds 
Persistance 

Slot Time, in 10s of milliseconds 

Link Frack 

Link Maxframe 

Link Retries 

Link resptime (acknowledge delay) 

Link CHECK 

Level 2 digipeat enable 0 = off, 1 = on 
Callsign validation, 0 = off, 1 = on 

Beacon mode, 0 = off, 1 = after traffic, 2 = always 
CQ enable, 0 = off, 1 = on 

Full Duplex, 0=simplex, 1 = suplex 

Send flags if no data need, 0 = no, 1 = yes 
007E byte RS-232 command lead-in character (escape) 
007F byte TxDelay, in 10s of milliseconds 

0080 80 byteDefault Password 

00DO byte Null byte for end of password, leave = 0 
00D1 80 byteINFOrmation message 

0121 byte Null byte for end of info message, leave = 0 
0122 word CW repeat rate, in seconds. 0 disables 


0124 byte CW bit speed in 10’s of milliseconds. 6 = 20 WPM 
0125 byte Default host mode. 
0 = normal 


1 = Hardware handshake connect control 

0126 byte Crosslink protocol control mode 

0 = TheNet normal crosslink protocol 

1 = Use KISS instead of crosslink 

2 = As per 1, also copy non node packets 

3 = As per 2 but copy all packets 

0127 byte MHEARD list length. 0 = off, max = 100 

0128 byte Node broadcast control. 

0 =no broadcast 

1 = HDLC port only 

2 = RS-232 port only 

3 = both ports 

0129 word RS-232 node broadcast interval, in seconds. 0 
disables 

012B byte Node broadcast algorithm control 

bit 0 = implement varient algorighm on HDLC 

bit 1 = implement varient algorithm on RS-232 

012C 8 byte Optional beacon digipeater list. End list with null 
character 

0134 word Default beacon interval in seconds 

0136 byte Connect redirection 

bit 0 = host 

bit 1 = bbs 

bit 2 = DxCluster 

0137 byte Pound node propagate. Each bit controls whether 
nodes whose alias starts with a ‘#’ are included in node 
broadcasts on a specific port. Bit 0 determines port 0 (the 
radio), bit 1 controls the RS232 port. If a bit is set, hash 
nodes are not broadcast. 

0138 4 byte This is the node TNC’s amprnet address. It is a 
numeric address of 4 bytes. For example if the address is 
44.131.16.31, then the data stored at each of the bytes 
138, 139, 13A and 13B respectively will be 1F, 10, 83 and 
2C. Contact your local coordinator for an address. 

013C 4 byte This is the amprnet address used by the node to 
recognise broadcasts. The data is stored in the same way 
as for the node’s address (as shown above). A typical 
address would be 44.131.0.0 for the UK. 
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0140 byte IP port mode control. This byte controls the default 
modes used for AX.25 frames on each port. If a bit is set, 
the default mode for that channel is datagram (UI frame), 
if not it is virtual circuit. 

bit 0 controls the radio port and 

bit 1 controls the RS232 port. 


0041 byte IP Initial time to live 
0142 byte IPenable. 0 = JP router disabled. > 0 = enable. 
0143 byte Help message control byte. Each bit enables or 


disables a different type of help message as follows: 
Bit 0 - ‘trying to connect’ message 
Bit 1 - sysop sees all commands in help 
Bit 2 - give a ‘godbye’ message to users 
Bit 3 - enables the connect text message 
Bit 4 - show nodes as alias:callsign 


The patch utility will not assist in changing the help 
text. That text is positioned at the end of THENET2.X1G. 
It is a null terminated string of characters. Newlines 
are represented by the value Oxd (decimal 13). It can 
be as long or as short as you like, but don’t forget that 
it causes the node to be a source of data and if very long 
could crash the node. 


Any problems, give me a ring ! 


4. The PATCH utility 

The patch utility is designed to help configure the two 
rom images in a manner that is not as user hostile as 
hand crafting a binary image. It is invoked as follows : 
PATCH [ file1 file2 ] 


If no parameters are given, it will look for files 
THENET1.X1G and THENET2.X1G in the current di- 
rectory. It will stop if it cannot load them. If the im- 
ages are renamed, they may be given as parameters. If 
this is done, both files must be given, with file1 corre- 
sponding to part 1 and file2 corresponding to part 2. The 
program is menu driven, with extensive help provided 
on the operation of the program and each parameter. 
It also tries to make sure that only valid data is entered. 


The program may also be instructed to load and save 
textual representations of the parameters. These con- 
sist of ASCII files, with one parameter per line. Each 
parameter consists of the name of the parameter, and 
equals sign, and the value for that parameter. The values 
are mainly numeric, with the obvious exceptions of things 
like the callsign, alias, password, info message etc. To 
get an example of the format, use the patcher to dump 
a file and look at it. The idea of this is not simply to 
load and dump whole images, but to load partial con- 
figurations such as passwords & info messages only or 
parameters only. The file may be edited to remove or 
add lines as desired. Note that each parameter MUST 
only occupy one line. For the information message, 
whitespace before the first printable character is ignored 
by the program, and if a newline is to be included, it is 
denoted by the sequence \m (ie backslash followed by 
the letter m). Similarly, to include the backslash char- 
acter itself, a double backslash must be entered, ie \\. 
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5. Programming examples 

There are two utilities included to facilitate conver- 
sion to hex for use in programming eproms. The source 
of both is also included if anyone wants a different file 
type. The programs have been compiled with Turbo C++. 


Each has the same method of invocation, 
INTEL infile outfile [ address ] 


or 
MOTOROLA infile outfile [ address ] 


These create INTELLEC or S1 type records respec- 
tively. Each reads an input binary file and outputs a 
hex version. The starting address assumed for the file 
will be 0000 unless specified otherwise in the command 
line. 


5.1 Intel format, loading as two halves 

¢ Use the patch program to create the desired 
image. 

¢ execute’: 

INTEL thenet1.xlg part1 

INTEL thenet2.x1g part2 

e¢ load part1 into the programmer and program the 
lower half of the eprom. Load part2 into the 
upper half. 

5.2 Motorola format, loading as one image 

¢ Use the patch program to create the desired 
image. 

e 6Execute : 

MOTOROLA thenet1.x1g part1 

MOTOROLA thenet2.x1g part2 8000 

COPY part1+part2 romimage 

e Edit romimage with a text editor to remove the 
intermediate end of file (SO... ) marker. 

e¢ Load romimage into the eprom in one go & 
program it. 

6. Acknowledgements 

Intel and Intellec are trademarks of the Intel corpo- 
ration Motorola is a trade mark of the motorola com- 


pany. 
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Bankswitching for TheNET X-1 


What follows is two versions of how to do the 
bankswitching. Saying things in two different ways is 
aneat way of making sure that ambiguities are exposed, 
so here goes. The first version is by me, the second by 
Bob G8HBE. 


For the reduced TNC2 version, the instructions are 
simply as follows : 


1. Bend out pin 1 of the EPROM so that when in- 
serted into the socket it will not contact pin 1 of the socket 
or any other pin. 


2. Connect a wire from the SIO-0 DTRA pin (pin 16) 
to the bent out pin (pin 1) of the eprom. The DTRA signal 
should also appear on pin 8 of the TAPR modem dis- 
connect header. 


Note trom KAZDEW: | recommend that you unplug the S/O, 
bend pin 16 up, reinsert the chip, and then solder directly to pin 
16. This eliminates a loading problem that might mess up the 
addressing operation 

The status led will flicker as it now shows the state 
of the bankswitch signal. 


One word of caution - if you can, just check the sig- 
nal on pin 1 of the eprom - make sure it switches fast 
and cleanly - i suspect that if it does not, errors will oc- 
cur. 


0 ———————_————__________—__— 


Robert Smith 38 Norris Close, Chiseldon, Nr Swidon, 
Wiltshire. SN4 OLR 


6 October 1991 
BANKSWITCHING for TheNet X1 


So that the 27C512 does not get damaged by the bend- 
ing of pin 1 and soldering it I have made the modifica- 
tion to the TNC-200, Tiny 2 and MFJ1274 type TNC’s 
as follows. 


To modify your TNC you will require a piece of thin 
connecting wire about 100 mm long and a 28 pin IC 
socket, you may also need a little bit of insulating tape. 
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Before starting the modification make sure that power 
to the TNC has been disconnected and that the lithium 
battery link as been removed. 


Remove the 27C256, U23 in a MFJ1274/TNC200 or 
U2 on a Tiny 2 and put it in a safe place. 


Taking your New 28 pin IC socket, bend pin 1 out- 
wards and solder the end of the wire to the bent out pin. 


Plug the IC socket into the socket you took the 27C256 
from, making sure that you plug it in the correct way 
round. 


Depending on the type of IC socket that is mounted 
on the PC board you may find that pin 1 on both IC sock- 
ets may touch, if this seems to be the case put a little 
pieces of insulating tape between them. 


Also on the Tiny 2 make sure that the bent pin does 
not touch the CPU chip. 


Now connect the other end of the wire to pin 16 on 
the Z80 SIO chip. 


This signal can also be found on pin 8 of the modem 
disconnect header which is J5 on a Tiny 2, also the same 
signal can be found on pin 5 of U6 (74HC14) on the Tiny 
2. On a TNC200 you can connect the wire to the side 
of R51 nearest U23, this is just 20 mm from pin 1 of U23 
on the TNC200 board. 


If in doubt use a test meter and check the continuity 
from pin 16 on the Z80 SIO chip to the point where you 
are going to solder the wire. 


Once you have done this you can plug the new 27C512 
Programmed with TheNet X into the new mounted IC 
sockets. 


Re-insert the lithium battery link, Connect your com- 
puter to the RS232 socket, 12 volts to the TNC and switch 
on, if all is working well the the STA light will be flick- 
ering and after a second a message will appear on you 
screen. 


Modification complete. G8HBE 6-Oct-91 
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Overview of Operation 


1. Introduction 

This paper introduces the main features of TheNet 
X-1G. This is an update to the previous paper on ver- 
sion X-1F. 


The software is a derivative of TheNet 1.01 by 
NORD><LINK. Additional commands and bug fixes 
have been included in the release. 


If your reaction is ‘What I really want is ......’, then 
please read on anyway, especially section 6. 


2. Structure 

One of the problems to extending TheNet is the 32K 
EPROM limitation imposed by the architecture of TNC2 
clones. The solution to this is to implement 
bankswitching. For the BSX2 TNC and similar TNC2 
clones, this can be achieved by the addition of a single 
wire as detailed in the bankswitch modification file. This 
is at the expense of the HIGH and LOW commands, and 
if anyone misses those commands, a version is available 
that implements them but required cut & stap mods to 
the TNC. 


3. New Commands 
The following commands have been added to the re- 
lease 


BYE DXCLUSTER 
BBS HELP 

HOST CTEXT 
STATS ALIAS 
MHEARD BBSALIAS 
MODE HOSTALIAS 
MANAGER DXCALIAS 
AUDIT QUIT 

TALK IPROUTE 
CALIBRATE ARP 

LINKS IPSTATS 
ACL IPADDRESS 
CLOSEDOWN IPBROADCAST 
BTEXT UI 


The following commands have been changed 


RESET 
the <escape> commands 


SYSOP 


Th following features have been added to the code 
An Internet Router 

e Ability to respond to three additional aliases 

¢ ACWID keyer 

e¢ The command processor has been extended KISS 

mode operation on the RS232 port 

HOST mode support on the RS232 port 

Remote configuration of all parameters 

Additional textual help messages 

In addition, a number of small changes have been 

implemented to satisfy the needs of specialist 

situations such as the ability to digi beacon 

packets. 


Network management in this context does not just 
mean ‘setting parameters remotely. It means the ability 
to set, read and interpret various monitors and diagnostic 
tools. Version X-1C included the first part of the net- 
work management, the MANAGER privilege and the 
AUDIT process. Version X-1D extends the auditing and 
statistics significantly including internal CPU monitors. 
Version X-1E includes most of the additions that are 
planned, and version 2 will complete the functions. No 
other release before version 2 was planned, but the need 
to produce a version with an IP router has prompted this 
release. The opportunity to experiment with additional 
features has therefore been taken. The next version will 
hopefully include significant changes attributable to 
Hayden Bate G8AMD. 


3.1 BYE or QUIT 

There are no parameters to these commands. When 
entered, they terminate the session. Both commands 
do the same thing. 


3.2 BBS 
The syntax of the command is : 
BBS [* | ? | callsign J 


With no parameter, the command connects to a sta- 
tion previously specified by the sysop. Setting the BBS 
destination is done by the use of the BBS command with 
a callsign as a second parameter. Setting the BBS to 
allow this may only be done by a sysop. The “’ option 
may also only be executed by the sysop, this command 
clears a previously specified BBS. 


The ‘? option (or any text if not sysop), prints out the 
current BBS station setting. 


If no BBS is set, the command issues an error mes- 
sage if it is invoked with no other parameters. 


The idea of this command is that, like with the ‘bbs’ 
command of the ‘BPQ software, a user may connect to 
the local BBS from the node. 


3.3 HOST 
The syntax of the command is : 
HOST [* | ? | callsign ] 


This command is very similar to the ‘BBS’ command. 
It allows connection to a local host, BBS or other server. 
The difference however, is that as long as the TNC is 
not in ‘crosslink’ mode (i.e. pin 23 on the RS232 port is 
high), and if a callsign is not set, the ‘host’ command 
connects to the local port. 


The idea of this command is that, like with the ‘bbs’ 
command of the ‘BPQ software, a user may connect to 
the local BBS, another node or server from this node. 
For example, if a print server were connected to the node 
in ‘host’ mode, this command would allow connection to 
it (like the ‘connect’ command with no other parameter). 
In KISS mode, setting a callsign or node alias allows 
connection to that system. 
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3.4 STATS 

The STATS command has no parameters. It prints 
a number of internal TNC statistics. In this version, 
this is limited to the level 1 stats of the radio channel 
and the internal clocks, the level 2 (AX.25), 3 and 4 sta- 
tistics, and the CPU health checks. 


For level 1, six pairs of numbers are printed, corre- 
sponding to the percentage of time the transmitter was 
on followed by the percentage of time the receiver DCD 
was on, for each of the last six 10 minute periods. The 
data is presented most recent period first. Two pairs 
of numbers are then displayed showing the transmit- 
ter underrun and receiver overrun. These are format- 
ted as per the level 2 stats with port 0 followed by port 
1 for the current hour followed by the totals for the pre- 
vious hour. In the case of the RS232 port, underruns 
are not possible, and an additonal error (framing) is 
included. The RX overrun includes overruns and framing 
errors. 

For level 2, the following are displayed : 
Frame checksum errors Total packets heard 
Total packets received by the node (ie sent to it) 
Total packets sent by the node 

Total receiver not ready packets sent 

Total reject packets sent 

Total receiver not ready packets received 


Total reject packets received 
Total number of link timeouts 


For each of the level 2 statistics, four numbers are 
shown. The first two are cumulative totals over the period 
of one hour, incrementing in real time. The last two are 
the totals for the previous hour. Each pair of numbers 
is the total for the radio port followed by the total for 
the RS232 (crosslink) port. 


For checksum errors, port 0 shows CRC errors and 
port 1 shows (when in ‘crosslink’ protocol mode only), 
checksum errors. As HDLC errors can be triggered by 
noise, acceptance of CRC errors is conditioned by the state 
of the DCD line. If DCD is on and an error is signalled, 
it will be added to the count. This reduces the false 
counts, but does not eliminate them. Distant stations 
that keep the squelch open (just) without being prop- 
erly heard will result in lots of apparent errors. 


For level 3, the number of level 4 frames gatewayed 
between nodes is displayed. 


For level 4, the number of transport frames sent and 
received by the node are shown. 


For level 3 and 4 statistics, two numbers are shown. 
The first is the number of frames accumulating for this 
hour, and the second number is the total number of 
frames for the previous hour. 


For CPU health checking, two statistics are shown, 
the CPU loading and the buffer usage. Each looks like 
the level 1 stats with 6 numbers corresponding to the 
last six 10 minute periods. 
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The CPU loading shows the number of times, divided 
by 100, that the CPU makes it around its basic inter- 
nal scheduler. For a node just switched on, receiving 
nothing, this will be about 470 ish for a 4.9 MHz clock. 
With lots of nodes, a heard list of 20 stations and 70- 
80% activity on the radio channel for it to listen to, this 
can drop to about 350ish. If it drops to double figures, 
worry, as the CPU is beginning to thrash. At low double 
figures, the CPU is pretty much working flatout. Time 
to up its clock rate !. 


The BUFFERS statistic shows the minimum num- 
ber of free buffers that the software had available to it 
during the last six 10 minute period. This indicates 
whether the TNC is failing to deliver data passed to it 
for onwards transmission, as well as how much data is 
backed up waiting. Additional stats needed to analyse 
this properly are not yet being collected. 


The display also shows the elapsed time since the last 
warmstart followed by the running time since the last 
coldstart. Each number is the number of hours of op- 
eration. 


3.5 MODE 
This command is similar to the PARAM command. 


It allows a number of other features of the software 
to be configured remotely. It removes the need for most 
of the host mode <escape> commands. 

The following parameters may be configured : 
The host mode 

The CWID send period 

The CWID keyer speed 

The port nodes broadcast control 

The crosslink / kiss control 

The Tx delay 

The full duplex flag 

The rs232 port node broadcast interval 

The node broadcast algorithm 

The beacon period 

The ‘connect’ redirector 

The ‘help message enable’ flags 

The ‘hash’ node broadcast port control 

Whether the node will listen for the extra aliases 


In operation, it behaves just like the PARAM com- 
mand. 


The parameters are as follows : 
3.5.1 Host mode control 

This parameter controls the ‘host’ mode. This is the 
mode of operation of the RS232 port when pin 23 is ‘high’ 


The valid values are 0 or 1. 


In mode 0, the port operates as per the standard node 
specification. Mode 1 is designed to allow connection 
to hosts or modems or similar equipment that expects 
a ‘CD’ type of signal to signify that an incoming / out- 
going connection is called for. 


In mode 1, the <escape> C and <escape> D commands 
are disabled and the other <escape> commands do not 
operate when connected. Instead, hardware handshakes 
are used to control conections to and from the TNC. 
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The TNC monitors pin 20 to determine the state of 
the host, and signals state changes to the host with pin 
5. When an incoming connect request is received (by 
the ‘ce’ command with no parameters or by the ‘host’ com- 
mand), the TNC raises pin 5 to signal the connection 
and expects pin 20 to change state in response. 


When the host wishes to place connect to the TNC, 
it signals on pin 20 and the TNC responds with by chang- 
ing the state of pin 5. 


It handles disconnects in a similar manner. Either 
the node or the host may initiate disconnects. 


This mode is experimental, changes may be made to 
its operation. It is designed for modems, print servers 
or hosts such as UNIX system tty login drivers. 


-38.5.2 CWID control 
The next two parameters control the CWID keyer. 


The first parameter is the CWID repeat period in 
seconds. Valid values are 0 to 3600. 0 disables it but 
do not set it below 120 apart from to disable it. 


The second parameter controls the keyer speed. Spe- 
cifically, it sets the number of 10 millisecond periods per 
dot and per inter symbol delay. 


The speed of sending is 120/n, so setting n to 6 gives 
20 wpm. Valid values are 4 to 10, corresponding to speeds 
of 30 and 12 wpm respectively. 


3.5.3 Node broadcast control 

This parameter allows control to be exercised over 
which ports nodes broadcasts are sent. Valid settings 
are 0 - 3. 


Value 0 disables node broadcasts. Value 3 (the de- 
fault) works as normal. A value of 1 enables broadcasts 
on the HDLC port only whilst a value of 2 enables broad- 
casts on the crosslink port only. 


3.5.4 Crosslink / kiss 

This parameter is used to set the communications 
protocol used on the crosslink port when pin 23 is tied 
low. 


The valid values are 0, 1, 2 or 3 


Mode 0 - standard crosslink protocol enabled Mode 
1,2,3 - use KISS instead of crosslink. 


In mode 1, KISS simply replaces the crosslink pro- 
tocol In mode 2, packets received from the radio part that 
are not intended for the node are copied to the RS232 
port in KISS mode. Similarly packets received on the 
RS232 port that are not intended for the node are sent 
to the radio port. In mode 3, all packets received on one 
port are copied to the other port as well as being analysed 
by the node. 


These modes are not simply KISS implementations 
that replace the node, they run with the node. 
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Mode 2 is designed to allow a KISS application and 
a node to share a radio without interference with each 
other. The point is that the PC TCPIP system can be 
switched off whilst leaving the node running to allow 
others to use it. . 


Mode 8 is a debugging mode. One problem when fault- 
finding on a node is that it is impossible to see what the 
node is seeing on the channel without replacing the rom. 
By setting this mode, it is possible to connect a KISS 
application to the RS232 port and observe what the node 
is seeing. 

Mode 3 is also designed to allow a PC running 
AXSTATS to be connected to the RS232 port to allow 
logging and analysis of channel performance from the 
node itself. 


3.5.5 Tx keyup delay 

This parameter sets the TX keyup delay in 10’s of mil- 
liseconds. This was previously done using an escape com- 
mand. 


3.5.6 Full Duplex 
This parameter sets or clears the full duplex control 
flag. This was previously done using an escape command. 


3.5.7 RS232 nodes broadcast interval 

When acrosslinked TNC is reset, it takes some time 
to learn about the nodes that the other TNCs can hear. 
Also, nodes heard by one TNC can take an hour to be 
notified to the others. 


In order to improve this, this parameter may be used 
to change the frequency of nodes broadcasts on the RS232 
port. When set to 0, the node operates as normal. When 
set to a non zero value, it will broadcast the nodes on 
the RS232 port at that interval. Hence setting it to 600 
would cause nodes broadcasts at 10 minute periods. The 
nodes broadcasts on the radio port will continue to oc- 
cur at the basic rate set by the PARAM setting. The 
obsolescence count will be decremented at the basic rate, 
not at the faster RS232 rate. 


3.5.8 Node broadcast algorithm 

This value controls the algorithm used. Bits within 
the value set have significance as shown below. There 
is a problem with the nodes broadcast algorithm when 
many TNCs are crosslinked on RS232. In order to ad- 
dress this a variation to the algorithm has been imple- 
mented for experimental purposes. Feedback on its use 
is requested. Bit zero affects the HDLC port and bit 1 
affects the RS232 port. When a bit is set to 1, the node 
broadcast algorithm is modified so that it will not re- 
broadcast on the same port a node heard on that port 
when the best quality neighbour is on that port. It makes 
little sense to use it on the HDLC port but what the heck, 
it is implemented for completeness. The only settings 
therefore that make sense are 0 and 2. These correspond 
to ‘normal’ and ‘modified on the RS232 port’ respectively. 
Setting it to 1 or 3 will result in some pretty weird ef- 
fects. 
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3.5.9 Beacon period 

This parameter sets the beacon interval in seconds. 
In TheNet 1.01, this was fixed at 10 minutes (600 sec- 
onds). In this version, this parameter may be used to 
change it according the the prevailing license conditions. 


3.5.10 ‘Connect’ redirector 

In TheNet 1.01, when ‘connect’ is given with no des- 
tination callsign, the node attempted to connect to the 
local host port. In a crosslinked system, this vanished 
down a black hole. In previous versions of this code, the 
node attempted to connect to the station set by the HOST 
command, only trying the local host port if no destina- 
tion was set by HOST. With this version, the node may 
be configured to connect to the station set by the BBS, 
DXCLUSTER or the HOST command depending on this 
parameter. When zero, connect attempts will go to the 
HOST station, when set to ‘1’, it will attempt to connect 
to the BBS callsign. When set to 2 it will attempt to 
connect to the DXCLUSTER callsign. 


3.5.11 ‘help message enable’ flags 

This word controls the sending of help messages, with 
each bit of the word controlling a separate function. Cur- 
rently, only 4 bits are effective, these being as follows : 
bit function 
Whether the ‘please wait, trying xxxx’ operates 
Whether all commands appear in help for sysop 
Whether the ‘goodbye’ message is given 
Whether a welcome message is enabled (CTEXT) 
Whether nodes are shown as ‘alias:callsign’ 


When bit 0 is set, and the BBS, HOST or DXcluster 
commands are given, then a message is sent from the 
node telling the user that a connect attempt is being 
made. This does not affect the ‘connect’ command it- 
self, unless the command is given with no parameter as 
this is then equivalent of the BBS or HOST command. 


When bit 1 is set, and if a sysop gives an incorrect 
command, the help screen shows all commands possible, 
including those currently disabled (as by definition they 
are not disabled for the sysop !). 

When bit 2 is set, then the use of the ‘bye’ command 
will solicit a ‘goodbye’ message from the node. 

Bit 3 switches on and off the ‘CTEXT’ message. When 
enabled, and when a CTEXT message is set, then when- 


ever someone uplinks to the node alias, the ctext mes- 
sage is sent immediately on connect. 


WN re © 


Bit 4 switches the way in which nodes are shown when 
the ROUTES command is used. When set to ‘1’, nodes 
are shown as “alias:callsign’. When set to 0, they are 
shown only as ‘callsign’. 
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3.5.12 ‘hash’ node port control 

In certain networks (notably the American), there is 
a need to restrict the propagation of local nodes. This 
is done by using node aliases that start with a hash char- 
acter (#) and instructing specific nodes not to broadcast 
routes to nodes that start with this character. This pa- 
rameter does this by enabling each port to be individu- 
ally enabled or disabled in respect to ‘hash’ node broad- 
casts. Bit 0 controls the radio port and bit 1 controls 
the RS232 port. When one of these bits is set, hash nodes 
will never be broadcast on that port. 


3.5.13 Extra aliases 

If this is set to ‘1’, then the node will listen for (and 
accept uplinks to) the aliases set in HOSTALIAS, 
DXCALIAS and BBSALIAS if they are set. If this pa- 
rameter is set to ‘0’, or if the respective aliases are not 
set, it will do nothing. If you do not use the aliases, set 
it to 0 to avoid wasting processor time. 


3.6 MHEARD 

The TNC can be instructed to keep a list of the last 
‘nn’ stations heard, where ‘nn’ is an integer between 1 
and 100. It can also be disabled. The syntax of the‘com- 
mand is : 
MHEARD [ nn J 


The parameter is optional and only operates for the 
sysop. It sets the maximum length of the list. Setting 
to zero disables the function. 


The heard list uses free buffers for the list, so a large 
setting means less RAM for the node software. 


The list is maintained as linked list, with the most 
recently heard station first. The display shows the num- 
ber of packets heard from that station and the time since 
it was last heard, in hours minutes and seconds. In 
addition, it shows the port on which the station was heard 
together with an indication as to whether the station 
is a node and/or a TCP/IP station. It does this by ex- 
amining the PID byte. 


Every hour the list is checked for stations that have 
not been heard for 12 hours, and any such stations are 
removed from the list. 


To disable the internal updating of the list (and thereby 
stop the CPU expending effort on the function), set the 
size to zero rather than just disabling the command as 
described in 3.8. Note though that the node will not clear 
the list as updates have been disabled, so it will be up 
to 12 hours before the buffers used are freed. To accel- 
erate this process, set the size to 1, wait until it has heard 
a station (any one will do) then set it to zero. This will 
free up all but one buffer immediately. 


3.7 CQ 


When CQ is disabled, the command now reports apolo- 
getically rather than simply ignoring the request. 
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3.8 ALL COMMANDS 

There is often a requirement to be able to disable the 
connect command whilst allowing level 3 relaying. This 
is achieved by the use of a command qualifier, the syn- 


tax of which is : 
CONNECT [ + | - ] 


If ~’ is entered by the sysop, then the connect com- 
mand will politely refuse to work. This can be reversed 
by the ‘+’ command. 


This has no effect of layer 3 relaying. Also, the BBS 
and HOST commands will still allow connections to be 
made if they are enabled and set. 


Further, the syntax is valid for ALL commands, for 
example the CQ command can also be disabled in the 
same way. Be careful though. The command is only 
accepted from the sysop, so if you disable the sysop and 
manager commands you will lock out remote manage- 
ment !. 


3.9 NODES 

When information on a node that is not known is re- 
quested, the program prints out an error message rather 
than giving the names of all known nodes. 


When a node entry is made by the sysop, callsign 
checking is forced ON rather than being determined by 
the callsign checking parameter. 


The entire contents of the node table routes may be 
obtained by the sysop or manager by the command 
NODES * * 


This will dump info on all nodes, one node per line, 
with the following format: 
Alias:call route1 route2 route3 


where routel, route2 and route3 comprise the qual- 
ity, obsolescense count and port followed by the neighbour 
callsign for each of the 3 route entries for that node. If 
any of the routes are in use, a chevron will be shown 
by that route. 


The extended command is only for sysop use as it, like 
auditing and conferencing, causes the node to be a source 
of a significant amount of data (dumping a large num- 
ber of node details can consume hundreds of buffers !!!). 
It is quite possible that used indiscriminately, it could 
cause a warmstart of the node. Be careful. 

3.10 RESET 

The syntax of the command is now 

RESET [ anything-else ] 


Entering the reset command alone will do a warmstart. 
If any other parameter is entered, a coldstart is per- 
formed. 
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3.11 MANAGER 

The MANAGER command gives the user extra privi- 
leges. In this version, this amounts to the ability to re- 
ceive audit messages from the node. The level of au- 
diting is set by the AUDIT command. 


The privilege remains in force until cleared by a com- 
mand that affects the user state. These are: entering 
the TALK state, executing the SYSOP command, enter- 
ing the MANAGER command and getting the password 
wrong, or disconnecting from the node. Failing to get 
the second password right when using the closedown 
command will also remove the manager privilege. 


If the MANAGER command is executed by a user who 
connected to the node by a level 4 circuit rather than 
by a level 2 circuit, and if the level 2 timeout is less than 
the no activity timeout, the connection will never timeout 
as the clearing and reconnecting of the level 2 circuit 
will keep the process alive provided level 2 auditing is 
enabled. This allows the operation of the node to be 
logged remotely and continuously. Alternatively, if the 
level 4 timeout is greater than 10 minutes, level 1 or CPU 
auditing will keep it alive if level 2 is switched off. NOTE: 
I have a nasty feeling that there is something not quite 
right - the link sometimes dies !. 


A user with MANAGER privilege also has SYSOP 
privilige. 
3.12 TALK 

Talk is a conferencing command. It allows a num- 
ber of stations to hold a simultaneous conference (a bit 
like the CONFERENCE command of a DX cluster). 
There is only one conference, and stations may connect 
to it by connecting to the node and issuing the TALK 
command. It may be exited by disconnecting or issu- 
ing the command /EXIT’ at the start of a line. (/EXIT 
may be abbreviated to /EX, and it is not case sensitive). 


Each line sent by a user is copied to all other users 
in the conference, preceded by the callsign of the user. 


Whenever a new station enters the conference, or a 
station leaves the conference using the ‘/EXIT command, 
the other conference users get a message informing them 
of the event. These status messages are sent with the 
callsign of the node rather than the user. 


Finally, when entering the TALK command, a mes- 
sage may be sent to all those users who are connected 
to the node but not otherwise doing anything. For ex- 
ample if GxABC enters the line 
TALK Hello fred, can | have a chat, type ‘TALK’ 

Then all other stations connected to the node, present 
in the USER list but idle, get the message 


GxABC>> Hello fred, can | have a chat, type ‘TALK’ 
displayed on their terminal. 


Note that merely connecting to the node does not 
consitute being connected to the switch. Stations con- 
nected to the switch appear in the USER list. 
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3.13 AUDIT 
The syntax of the audit command is: 
AUDIT [ new-value ] 


where new value is an integer value. If no value is 
given, or the user does not have SYSOP status, the cur- 
rent mask value is displayed. Otherwise, the mask is 
updated and the new value displayed. 


The mask controls the auditing of various events in 
the node. Not all values are used yet, but those that 
are, are: 
bit function 
0 Level 1 statistics on 10 minute updates 
1 Level 2 connects & disconnects 
2 reserved for future use 
3 Level 4 connects & disconnects 
4 Level 7 limited events (use of sysop) 

5 Full level 7 auditing 6 CPU auditing messages (10 minute 
updates) 


It is suggested that the usual settings can simply be 
0 or 255. 


For level 1, messages are sent every 10 minutes show- 
ing the percentage of time that the receiver detected car- 
rier and the percentage of time that the transmitter was 
on. 


At level 2 & 4, the messages are of all connects and 
disconnects, shown in 4 different ways : 


C Connect message received by node 
CA Connect message sent / Acknowledge received 
D Disconnect message received by node 


DA Disconnect message sent / Acknowledge received 

In each case, 2 callsigns are shown. At level 2 these 
are the source and destination of the AX.25 link. At level 
4, itis the remote node callsign and user callsign. Each 
message is preceded by an indication of the source of the 
message, such as “L2” or “LA”. 


At level 7, with bit 4 set and bit 5 clear, the only event 
currently audited is the use of the Sysop command, ei- 
ther directly or via the manager command. If bit 5 is 
set, then all commands given to the switch are audited, 
preceded by the callsign of the user who entered the com- 
mand. 


Bit 6 controls CPU health check auditing. If set, then 
whenever the internal CPU statistics are updated, mes- 
sages are sent showing the CPU processor loading to- 
tal and the minimum buffers level (see STATS for more 
information). 


The audit mask value should be set to 0 when not ac- 
tually being used. Do not leave it set to another value 
as this wastes processor time. Note also that full au- 
diting on a busy node makes things worse. Treat it as 
a debugging feature !. 
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3.14 SYSOP 

The SYSOP command has been enhanced to increase 
the level of security offered. One problem of the old sys- 
tem is that the password is easily visible unless the user 
repeats the SYSOP command a number of times. Even 
then, correlation between passwords is easy, so the pass- 
word needs frequent changing. To reduce the change 
period, and make it harder to discover, the node will ac- 
cept a string of characters and scan it for the password. 
Hence a response of, say, 30 or 40 characters can be sent, 
with a random number of random characters preceding 
the actual data and a random number following it. This 
does not eliminate such attacks, but if used carefully, 
it makes it quite a bit harder to attack. 


3.15 LINKS 

This command shows the current level 2 links to the 
node. Displayed one per line, the two callsigns are shown 
followed by the link state, port number and current re- 
try count. 


3.19 CTEXT 

The CTEXT command sets or displays a message sent 
to a user who connects to the node by uplinking to the 
node’s alias. 


The syntax of the command is : 
CTEXT [ message ] 


With no parameter, the current message is displayed. 
If the user is also a sysop, and if text follows the com- 
mand, that text becomes the new connect text. When 
a‘* is encountered, the message is terminated (it is also 
terminated by a newline). Hence, to clear the message, 
type the command ‘ctext *. 


A message is only sent if there is a ctext message set 
and if the relevant bit is set in the mode command pa- 
rameter as described in section 3.5.11. 


3.20 BTEXT 
The BTEXT command sets or displays the additional 
beacon text sent along with the beacon packets. 


The syntax of the command is : 
BTEXT [ message ] 


With no parameter, the current message is displayed. 
If the user is also a sysop, and if text follows the com- 
mand, that text becomes the new beacon text. When a 
“* is encountered, the message is terminated (it is also 
terminated by a newline). Hence, to clear the message, 
type the command ‘btext *. 


Normally, beacon packets are UI frames that contain 
the node callsign and alias. If a beacon message is set, 
the text of the message follows the alias in the same 
packet. It is strongly suggested that beacon packets be 
kept brief !!!. 
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3.17 DXCLUSTER 

The DXCLUSTER command operates just like the 
BBS command in that it may be used to effect a con- 
nection to a DXcluster (assuming there is one nearby). 
It should be disabled if it is not intended to be used to 
access a cluster. 


The syntax of the command is: 
DXCLUSTER [ * | ? | callsign ] 


With no parameter, the command connects to a sta- 
tion previously specified by the use of the DXCLUSTER 
command with a callsign as a second parameter. Set- 
ting the DXCLUSTER to allow this may only be done 
by a sysop. The ‘* option may also only be executed by 
the sysop, this command clears a previously specified 
DXCLUSTER. 


The ‘” option (or any text if not sysop), prints out the 
current DXCLUSTER station setting. 


Ifno DXCLUSTER is set, the command issues an error 
message if it is invoked with no other parameters. 


The idea of this command is that, like with the ‘bbs’ 
command of the ‘BPQ software, a user may connect to 
the local DXCLUSTER from the node. 


3.18 HELP 

The HELP command gives a message from the ROM. 
In general, it is expected that the message will be de- 
signed to assist new users in understanding the opera- 
tion or configuration of the node. The message may span 
many lines, and may be changed when the rom is pro- 
grammed. As delivered, it contains a brief help screen 
detailing the main (user) changes to the code. 


3.21 ACL 

This is probably the most complex additonal command 
in the program. It should be used with care, and only 
when you really understand its operation - mistakes can 
result in the need to go out to a remote site (probably 
when it is cold and wet) to reconfigure the node. 


The command allows selective control, based on call- 
sign, of a list of different events. The ACL contains two 
types of entry, a default value and zero or more callsigns, 
each of which are associated with a value. When one 
of the controlled events occurs (such as an incoming level 
2 connection or a nodes broadcast), the ACL is scanned 
for an entry that matches the callsign of the sender. If 
a match is found (but see below), the value associated 
with that callsign is used to determine the action the 
node will take. If no match is found, the default value 
is used. 


Each bit of the value controls a different function: 
it function 
bar incoming level 2 connection 
bar outgoing level 2 connection (downlink) 
ignore nodes broadcasts from this station 
bar gatewaying at level 3 to/from this station 
bar incoming level 4 connections 
bar outgoing level 4 connections 
ignore SSID in matching an entry 
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So if for example an entry exists for a callsign GO9XXX 
of 6, then the node will not allow outgoing level 2 con- 
nections to the node (downlinks), and will ignore node 
broadcasts from that station. Note that these commands 
only operate on the events themselves - if G99XXX cre- 
ates a level 2 connection, the node will quite happily use 
it itself. 


The ‘ignore ssid’ bit is used to match a callsign with- 
out regard to its SSID. This makes life interesting when 
finding a match, so the list is scanned twice, once for 
an exact match, and then for a match ignoring SSID if 
an exact match is not found. There can only be one ex- 
act match, but when searching for a match without us- 
ing SSID, the first entry found will be used. 


The syntax of the command is as follows (3 versions) 
ACL * value 
ACL callsign + value 
ACL callsign - 

If you are not sysop, or if ACL is given on its own, the 
current contents of the ACL are shown. The first form 
of the command changes the default value, the second 
form makes an entry in the list, the last form removes 
an entry from the list. It complains about syntax er- 
rors. 


A few moments thought will show that the sequence 
of commands 
connect to node 
execute sysop or manager command 
type the command ACL * 127 
disconnect 


is quite catastrophic. You will not be able to get back 
in again apart from via the host port and noone will be 
able to connect to or from the node. If you intend to 
experiment with the command, you should start by en- 
tering your own callsign with a value of zero to ensure 
that you can get back in again !!!. 


The list can be used as an ‘accept’ or ‘reject’ list by 
judicious use of the default. To create a list that excludes 
specific calls, put them into the list with the required 
bits set in the value. The default should be zero. To 
create an ‘accept’ list, put entries in with the required 
bits zero and set the corresponding bits in the default. 
Individual bits may be used to create accept or reject 
lists for each function. 


The command steals buffers at a rate of one buffer 
per four entries in the ACL. Also, a long ACL will slow 
the node down nicely - so think before you enter a long 
list. 


This command is for experimental purposes - if you 
find any bugs, let me know please (I have not fully tested 
the gateway bit for example). Also, it is not intended 
for malicious use but to allow fine control to be exercised 
over backbone networks. If I get lots of negative re- 
sponses back, the command will go ! 
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3.16 CALIBRATE 

This command allows remote calibration checks of the 
transmitter deviation. Its syntax is 
CALIBRATE period [ toggle ] 


The period (1 to 60 seconds), is the time for which the 
transmitter will key up for with constant tone. It is un- 
defined as to which tone will be sent. If the second pa- 
rameter is given, the node will toggle between the tones 
every [toggle] seconds. The toggle must be between 1 
and [period] seconds. Ifa period is not given, the user 
is not sysop or manager, or if it is out of range, the com- 
mand is ignored. If the tone generator is busy because 
it is about to send a CWID sequence, a ‘busy’ message 
is returned. Note - quite often it can appear that the 
node has locked up having failed to transmit the full 
calibrate period. In fact, this is usually the hardware 
PTT watchdog in the TNC. The node thinks it is still 
sending but the hardware timer has removed the PTT 
signal. 


3.22 CLOSEDOWN 

The closedown command is used to shut down the node 
remotely. If successfully executed, the node will effec- 
tively stop operating until it is reset (eg by a power up). 
The node’s configuration (routes, messages etc) are not 
destroyed - the node simply hits a HALT instruction. 
You must be sysop to execute the command. 


The syntax of the command is: 
CLOSEDOWN A 


The node will respond with 5 numbers just as for when 
the sysop or manager command was executed. Yes, you 
guessed, the node expects another password. Give it 
correctly and the node closes down completely. Get it 
wrong and you lose your sysop status. This obtuse and 
awkward syntax is designed to make sure it is not ac- 
cidentally executed. 


3.23 ALIAS 

The ALIAS command allows the node’s alias to be 
changed. The syntax is : 
ALIAS [ * | new-alias ] 


If no parameter is given, or if the user is not SYSOP 
or MANAGER, the current alias is displayed. Ifthe alias 
is deemed to be a valid alias, the node’s alias is changed 
to the new one entered. Note that the algorithm that 
checks for the alias structure is a bit queer. It is how- 
ever, the original algorithm of TheNet and I am loth to 
change it for fear of side effects. Note too that the com- 
panion CALLSIGN command is NOT included - chaos 
is not something I crave. If the sysop gives the param- 
eter of “’, the node’s alias is cleared. 
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3.24 BBSALIAS HOSTALIAS DXCALIAS 

These commands are used to enable the node to re- 
spond to up to three additional aliases. The syntax of 
each is the same, and by way of example the BBSALIAS 
syntax is : 
BBSALIAS [ * | new-alias ] 


If not sysop, if no new alias is specified, or if it does 
not pass the weird alias syntax checker (see 3.23) then 
the current alias is displayed. If not, the alias is changed. 
If ‘* is given, the alias is cleared. 


The aliases so entered are nothing to do with the node’s. 
identity. Ifa BBS alias is set, for example to MXMBBS, 
then the node will listen for level 2 connects to that alias. 
It will respond to them and will automatically invoke 
the BBS command. The use will also get the optional 
welcome (ctext) message and ‘trying to connect to ....’ 
messages if enabled by the appropriate ‘mode’ param- 
eter. 


The idea is that where a node sits on a channel that 
does not have access to the local host, BBS or cluster, 
the normal aliases of those stations may be enabled in 
the node to allow consistent access to the local services. 
Note that the three stations do not have to be a BBS, 
Host and cluster, it could be three BBSes or any other 
combination. 


3.25 IPSTATS 

The IPstats command has the same basic syntax as 
the PARMS and MODE commands. When invoked 
without parameters, it displays the current stats. Each 
statistic may also be altered by sysop. 


In addition to the standard IP MIB, there is an ad- 
ditional parameter used to set the level 2 default modes, 
and the first entry in the MIB is used to enable or dis- 
able the router. 


The complete set of IP MIB stats are included for com- 
patibility with other IP systems, but several are not used. 
Also, the stats are 16 bit counters not 32 bit counters 
as in NOS. Like NOS however, the stats do not reset 
every hour, they must be cleared by the sysop. They 
will however wrap around at zero. 


The entries are: 


1 Port default modes 11 IP Output Requests 

2Enable/ Disable IProuter 12 IP Output Discards 

3 Default IP Time To Live 13 IP Output No Routes errors 

4 IP Received frames 14 IP Reassembly Timeout errors 
5 IP Header Errors 15 IP Reassembly Required errors 
6 IP Input Address Errors 16 IP Reassembly OKs 

7 IP Forwarded Datagrams 17 IP Reassembly Fails 

8 IP Unknown Protocols 18 IP Fragmentations completed 


9IP input frames Discarded 19 IP Fragmentation Failures 
10 IP Input frames Delivered 20 IP Fragmentation Creates 


The default mode word may be set to 0, 1, 20r 3. Each 
bit controls a port, with bit 0 controlling port 0 (radio 
port) and bit 1 controlling port 1 (RS232 port). When 
set to 1, the default mode for that port when sending 
on a level 2 connection will be Datagram. When set to 
0 it will be by Virtual Circuit. The default mode is used 
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when no other information is given, either by the ARP 
table or by the TOS bits in the IP header. 


The enable/disable word may be set to 0 or 1. When 
set to 0, the operation of the router is stopped, when set 
to 1 the router functions. 


The IP Time To Live (TTL) word is used to set the 
number of routers through which an IP frame may pass 
before it is discarded. It is similar to the node layer 3 
TTL word. It may be set to any value up to 255, but 
values below 2 make no sense and are therefore not 
permitted. 


The IP fragmentation reassembly timeout counter is 
not used as the node is just a router. It is left set to 30 
seconds just to show which one it is ! 


The rest are just statistics. The patient user can have 
hours of fun working out which ones are not used (or 
just think about it for a second or two). 


3.26 IPADDRESS & IPBROADCAST 

These commands are used to set or display the IP 
addresses used by the node. The syntax of each is (by 
way of example): 


IPADDRESS [ ipaddress ] 


where ipaddress is in the form 
nnn.nnn.nnn.nnn 


where nnn is an integer in the range 0..255 


So to set the node IP broadcast address to that used 
over here, the command would be : 
IPBROADCAST 44.131.0.0 


The IPADDRESS is the address that the node will 
respond to. It is used only as detailed in section 7. The 
IP broadcast address is the one used to denote broad- 
cast packets that will be largely ignored. Note that port 
addressing is NOT currently supported. Anyone who 
finds this limiting, drop me a line and Ill see if I can 
change it. 


3.27 IPROUTE 

This is one of the two main databases used by the node. 
The IP Route table is used to tell the router where to 
send a frame for a specific detination. It maps addresses 
or address ranges to a gateway IP address and to sub- 
network ports. The ARP database then tells the node 
what station corresponds to that address and protocol. 
The node supports two subnet protocols, AX25 and 
Netrom. 


The database is stored in an ordered list, in decreas- 
ing order of the number of relevant bits. This is to per- 
mit searching of the database when trying to find a spe- 
cific destination. Given an address, it scans addresses 
with decreasing numbers of bits until it finds a match. 
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The syntax of the command is as follows : 
IPROUTE [address [ / bits ][ + port [gateway [metric] 


or 


IPROUTE [address [ / bits JI - ]] 


In the first form, it makes an entry in the table, in 
the second it deletes one. Only sysop or manager may 
effect such a change. The parameters are as follows : 


address The amprnet address in the form 
nnn.nnn.nnn.nnn 

bits The number of significant bits (eg 
44.131.0.0/ 16) 

port The port, either 0 or 1 for AX25 orn for 
NETROM 

gateway ‘The optional gateway for this dest. 
nnn.nnn.nnn.nnn 

metric Currently not used, a numeric value 


When an entry is made with a specific number of bits, 
the address is ‘masked off to that many bits, so enter 
an address of 44.131.16.31 / 24 and it will get entered 
as 44.131.16.0. The valid range for the number of bits 
is 1 - 32. 

3.28 ARP 

The ARP table maps a pair of address+port to hard- 
ware address+subnetwork mode. The address is either 
a destination or a gateway in the form nnn.nnn.nnn.nnn. 
The protocol is either netrom or ax25. The 
hardware_address is a callsign and the subnetwork mode 
is DG or VC (only has significance for level 2 links). 


The syntax of the command is : 

ARP [ destination [ + [ P ] protocol callsign [ mode ] ]] 
or 

ARP [ destination [ - protocol ] ] 


In the first form an entry is made in the table, in the 
second an entry is deleted. This is only permitted for 
sysop or manager. 


The parameters are : 
destination An address of the form nnn.nnn.nnn.nnn 


P If present, marks the entry as ‘published’ 
protocol AX25 or NETROM 

callsign A valid amateur callsign, e.g. G8KBB-5 
mode DG or VC 


If P’ is entered, then the node will publish the address. 
Specifically, if an ARP request is seen by the node for 
a station with the address given, it will send a response 
advising the caller of the callsign to be used. 


More details on the operation of the router are con- 
tained in section 7. 
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3.29 UI 

The UI command allows a string to be sent as a Level 
2 UI frame. The syntax is 
UI dest string_of_text_ending_in_return 


Dest is a callsign like destination such as ‘MAIL’. What 
will happen is that a single UI frame will be sent with 
a source callsign of the user who entered the command,a 
destination callsign of dest, and the rest of the string 
as text. 


It is designed to be used in situations where a local 
BBS does not have access to a common channel and 
wishes to send mail notification packets. Not surpris- 
ingly, the ability to do this is BBS specific. 


4. Other Changes 
This section covers the other miscellaneous changes 
to the software. 


4.1 Command Processor 

The command processor has been altered. In general, 
but not in all cases, commands only appear on the ‘help’ 
menu when they are enabled, so for example the ‘BBS’ 
command will not be shown unless it has been enabled 
with the ‘BBS +’ command. The exception is the sysop 
commands, like MODE, LINKS and PARAM, which are 
never shown to users but are of interest to them. Ifthe 
appropriate bit is set however in the MODE command 
(see 3.5.11), then for the sysop or manager, all commands 
appear in the help prompt - even if disabled. 


The help screen now shows commands in a combina- 
tion of upper and lower case characters. 


4.2 Beacon digi 

It is possible to set a digi in the address used for beacon 
packets. Details of how to do this are contained in the 
configuration guide. Note that this is provided for those 
rare occasions when there is a genuine need. This is 
rarely the case and should not be done unless really nec- 
essary. 


5. CWID keyer. 

The CWID keyer sends the station callsign in CW by 
alternating between the two modem tones. This is nomi- 
nally sent at 20 wpm once every 30 minutes, but the 
speed and period can be changed remotely. 


After a delay of 30 minutes, the callsign is sent ap- 
pended to the end of the next data packet that is sent 
over the air. There is a 500 ms delay after the end of 
the data packet before the call is sent. 


The program prefers to send CWIDs appended to or- 
dinary data packets. However, if one minute after the 
CWID has supposed to be sent it is still pending because 
no data packets have been sent, it will key up the trans- 
mitter anyway. Persist, TxDelay and other parameters 
are honored, but the process involves changing the SIO 
mode and this will have an aggrevating effect on any 
packets being received in full duplex mode. 
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6. Version X-2. 

X-1 was the first release of this code. The objective 
is to get some practical feedback and test the code be- 
fore the full release, version X-2, which I hope will be 
very similar to this release (X-1G). I have been saying 
this for some time now, but things keep getting added. 
The next version will hopefully be a significant change 
with extensions from G8AMD, but this may be some time 
off yet... 


Version X-1A added the escape-N command and the 
change to the connect, nodes and reset commands. The 
timers were also added to the stats command. 


Version X-1B removed all the escape commands apart 
from C,D and P. It also added the MODE command and 
extended the + and - command qualifiers to all com- 
mands. 


Version X-1C added TALK, MANAGER and AUDIT. 
The SYSOP command was enhanced and the INFO com- 
mand was altered to limit the length of a message (a 
bug in the original version of TheNet). The help screen 
was changed to display commands in a combination of 
upper and lower case. 


Version X-1D extended the auditing and statistics to 
cover auditing everything but level 3, and statistics of 
the CPU, Level 1, Level 2 and timers. 


Version X-1E added beacon timer control, the connect 
redirector, the nodes dump facility, level 3 & 4 statis- 
tics and the LINKS and CALIBRATE commands. 


Version X-1F added the CLOSEDOWN, ACL, CTEXT, 
DXCLUSTER, HELP and BTEXT commands. Another 
parameter was added to the MODE command to con- 
trol textual messages. The mod suggested by DF2AU 
to correct the DCD latchup was included. Additional 
statistics were added covering CRC errors, receiver over- 
run, transmitter underrun and framing errors. 


Version X-1G added mainly the IP router, with the 
following commands to control it - IPROUTE, ARP, 
IPSTATS, IPADDRESS, IPBROADCAST. In addition, 
the ALIAS, BBSALIAS, HOSTALIAS and DXCALIAS 
commands crept in, as did QUIT as an alternative to 
BYE. The help messages extended to enable nodes in 
the routes list to appear as alias:callsign, and an extra 
byte on the MODE command allowed ‘#’ nodes to be 
selectively NOT broadcast. The order of HELP and 
HOST commands changed so that ‘h’ on its own gave 
help not host. The code was optimised with some time 
critical parts being recoded in assembler and a peephole 
optimiser being used for additonal improvements. 


If you read this and say ‘Pah. it doesn’t do XXXXX’ 
or ‘It still doesn’t do YYYYY’ or anything of a similar 
nature, don’t keep it to yourself. Tell me. I may well 
do it. An example of this is a concern raised about the 
way the nodes broadcast works on a multi-tne crosslink. 
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7. The IP router 

The IP router co-exists in the node with the other soft- 
ware. It is connected to the L2 and L3(netrom) proto- 
col machines, and is managed from the 17 switch. It will 
accept data from L2 Datagrams, L2 Virtual Circuits or 
NOS protocol extended netrom frames. It will output 
to these 3 depending on the setting of the I[Proute and 
ARP tables. 


The router supports the IP options of NOS and also 
does IP fragmentation. Level 2 segmentation is not sup- 
ported. In addition, ICMP is implemented in so far as 
it is needed to respond to errors or PINGs. No higher 
layer support is provided, ie TCP is not implemented, 
ip_send() and ip_receive() are only implemented in so 
far as they are needed for ICMP. You can therefore PING 
it but anything else will solicit an ICMP error message. 


It will respond to ARP & REV_ARP requests but will 
never initialte them. The MTU is 256 for AX.25 and 
236 for netrom. It will accept longer datagrams than 
this and fragment the output but it is not recommended 
as it merely wastes RAM. It is possible to be creative 
in the use of L2 datagram and virtual circuits by use 
of the port default settings and the ARP table. The al- 
gorithm used is : 
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When a frame is to be sent, the ARP table is scanned 
for the appropriate entry. The entry tells it what call- 
sign to use. For netrom encapsulation, it is sent to the 
netrom protocol handler. For AX.25 encapsulation the 
following applies. The ARP table may indicate DG or 
VC. In this case, that mode is taken. If there is no DG 
or VC entry, the TOS bits are examined. If the delay 
bit is set, a datagram mode is selected. If not, and the 
reliability bit is set a virtual circuit is selected. If nei- 
ther bit is set, the default mode for that port is used to 
select a mode (see IPstats command, first parameter). 


Port addressing is not supported at the moment. 


The IP router is manually controlled - no rspf or rip, 
or even arp requests. This is because 32K of RAM does 
not allow such niceities as queueing frames whilst waiting 
for address resolution. 


8. MISC 
Anyone interested in a copy of the program, drop me 


a message on GB7MXM.#36.GBR.EU Also, any sugges- 
tions for change gratefully received. 


Dave G8KBB 
7Rowanhayes Close 
Ipswich IP2 9SX 
England 
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User Guide for TheNet X-1G 


This brief note is intended for users of TheNet X-1G, 
and explains the basic commands. Configuration and 
sysop features are not covered fully. 


TheNet X-1G is an extension of TheNet 1, and pro- 
vides a number of new features. 


The switch provides the following user commands : 


Connect Talk Bye 

Info CQ DXcluster 
Nodes BBS IProute 
Routes Host ARP 
Users MHeard QUIT 


Not all commands may be available on every node as 
certain commands might have been disabled. If a com- 
mand has been enabled, it will be displayed when you 
type an invalid command such as “”’. In addition, there 
are some commands that are available but are not dis- 
played. The main ones of interest are : 


Links Stats BBSAlias 
Mode IPAddress HostAlias 
Parms DXCAlias 

Connect 


If the connect command is given on its own, then as- 
suming that the sysop has set it up correctly, you will 
get connected to the local BBS. 


If you give another callsign, either of a local station 
or a node, the node will attempt to connect you to that 
station either by a level 4 connection or by downlinking. 
If you are downlinking, you may also specify digipeat- 
ers. 


In either case, you get either a connected message or 
a message telling you of the failure to connect. If you 
enter any other command at this stage, the connection 
attempt will be aborted. 


Info 

This command gives information about the node as 
a combination of a message stored in the EPROM and 
a message entered by the Sysop. 


Nodes 

This command gives information about the distant 
nodes that this node thinks it can get to. With no pa- 
rameter, it shows the alias and callsign of all the nodes 
except those staring with a ‘# character. If a param- 
eter of ® is given, those ‘hidden’ nodes will also be shown. 


If a callsign or alias is given that the node does not 
know, it gives an error message. If the callsign or alias 
of a known node is given, the node gives details of the 
routes it knows about that lead to that destination. The 
display shows one option per line, each of which consists 
of the path quality, obsolescence count and port followed 
by the callsign of the neighbour. If any route is in use, 
a chevron is shown against the appropriate entry. 
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Routes 

This command gives information about the 
neighbouring nodes that can be heard. For each 
neighbour, the display shows the port number, the call- 
sign, the path quality and the number of nodes acces- 
sible through this neighbour. Ifa route has been ‘locked’ 
by the sysop, then a ‘’ character is shown after an en- 
try. The sysop may have configured the node to display 
nodes as callsign or as alias:callsign. 


Users 

This shows who is using the node. It does not show 
other nodes that are using the node as a level 3 relay, 
nor does it show those users who have connected to the 
node but otherwise have done nothing. 


The display shows the through connections, followed 
by those users who are connected to the switch and ‘idle’. 
It also shows those users who are connected to the con- 
ferencing facility. The latter stations are shown con- 
nected to a destination called ‘Talk’, whilst in the case 
of connections, the two endpoints are shown. For con- 
nections, two symbols are used, ‘<—>’ and ‘<..>’. The 
former is used for established connections whilst the 
latter is used for connections being established. 


Talk 

The Talk command allows a group of users to hold a 
conference call. It also allows a user to send a message 
to another user of the node provided that user is con- 
nected to the switch but is not patched through to an- 
other station and is not currently tyring to connect to 
another station. 


A user enters the conference by giving the command 
‘talk’. He/she gets a message informing them of this and 
reminding them that the command to escape from the 
talk command is /exit?. Any other users currently in the 
conference get a message from the node telling them of 
the callsign of the user who has joined them. At this 
point, every line sent by a user in the conference is copied 
to all other users in the conference, preceded by their 
callsign. 


To exit from the conference, the command ‘exit’ is used. 
This causes a response message to be sent to the user, 
and at the same time all of those left in the conference 
get a message from the node telling them of the station 
who has left the conference. If you force a disconnect, 
the other stations are not told of your departure. 


A string of text may be entered on the same line as 
the talk command when the command is given. If this 
is done, before the user is connected to the conference, 
that string of text is sent to all the other users of the 
node who appear in the ‘user’ list but are not connected 
to anything else. For example if GxABC were to type : 
TALK GyXYZ, Hello fred can I have a chat - type TALK 

then other users of the node (including presumably 
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Fred, would get the message : 

GxABC>> GyXYZ. Hello fred can I have a chat - type TALK 
on their screens. The only exception to this is that 
sysops are not sent the message. 


cq 

This command is used to broadcast a CQ message. 
In addition, the fact that you are calling CQ is indicated 
in the USER list. The callsign will be your own witha 
different SSID, and anyone else can connect to you by 
connecting to the callsign with the appropriate SSID. 


The CQ remains ‘primed’ for a while, and if any other 
command is given to the node the CQ will be cancelled. 


BBS 

When you issue the BBS command, assuming that 
the sysop has configured it, you will be connected to the 
local BBS. 


If you enter the command ‘BBS ?’, then the current 
setting of the BBS will be displayed. 


Host 

The HOST command operates just like the BBS com- 
mand. It may have been disabled by the sysop, it may 
have been set to connect to the same station as the BBS, 
or it may have been set to connect to another host sys- 
tem. 


If you enter the command ‘HOST ?’, then the current 
setting of the HOST will be displayed. 


MHeard 

If enabled, the heard list shows the last few stations 
heard. The display shows the number of packets heard 
from that station since it appeared in the list and the 
time since it was last heard. The time is hours, min- 
utes and seconds. The list also shows the port on which 
the station was heard (port 0 is the radio port), and if 
it hears IP frames or Net/Rom frames, it adds a note to 
show that the station is a node and/or a TCP/IP station. 

If the list is long enough so that a station is not heard 
for 12 hours, it will get deleted anyway. 
Links 

The LINKS command shows the level 2 connections 
to the node. This is usually of academic interest, but I 
use it in testing. The display shows the links, one per 
line, with the two callsigns, the link state, the port num- 
ber and the current number of retries. 
Arp 

This command is similar to the [Proute command, but 
shows the Arp table. The Arp table provides a trans- 
lation from Ip address to callsign. 
IPaddress 

This command is used to display the node IP address. 
IProute 

This command is used by the sysop to configure the 
IP route table. It may also be used to display the router 
table. 


Mode 
The MODE command is a bit like the PARMS com- 
mand. It shows a number of additional parameters. 
These are as follows as shown by example : 
MODE THENET:G8KBB-5> 0 1800 6 3 2 20 0 600 2 900 1 3101 
with the following meanings : 
Host mode protocol (0 = standard, 1 = DCD mode) 
1800 CWID period. Delay in seconds between CWID 
6 CWID speed 10’s of msec per dot. 
6 equals 20 wpm 
3 Enable / disable nodes broadcasts mask. 
2 RS232 protocol, 0 = crosslink, 1,2 or 3 are KISS 
20  TxDelay in 10’s of milliseconds (Centiseconds ??) 
0 Full duplex control. 0 equals simplex 
RS232 port nodes broadcast interval in seconds 
2 Nodes broadcast algorithm port mask 
Beacon period in seconds 
1 ‘connect’ redirector. 0 is to HOST, 1 is to BBS 
31 Each bit controls one of the ‘user’ help messages 
0 This byte controls the broadcasting of ‘hash’ nodes 
1 This byte enables / disables the extra alias operation 


If you want additional details, ask the sysop for a copy 
of the overview guide. (/nteresting how not all of the users 
where this was written get this entire book dumped on them 


like they do in NAPRA hmmm.-ed) 


Parms 
This shows the node parameters as per TheNet 1.01 
(I am not going to list them again here. Sorry). 


Bye and Quit 

These commands disconnects you from the node, clos- 
ing the link. It says goodbye before disconnecting you 
if it has been so configured by the sysop. Quit does just 
the same as Bye does. 


DXcluster 

If there is a local DXcluster, this command may have 
been configured by the sysop to connect you to it. It 
therefore operates in a manner very similar to the BBS 
command. 


Stats 

The stats command gives lots of data about the node 
operation. A full description of the information is con- 
tained in the overview document. 


BBSAlias HostAlias DXCAlias 

These commands are used to set additional aliases 
for the node. It can be configured by the sysop to ac- 
cept connect requests (uplinks) to the node callsign, the 
node alias, or the 3 aliases shown by these commands. 
When the node accepts a connection to one of these 
aliases, it will immediately invoke the BBS, DXC or 
HOST commands for you. The way this would be used 
is as follows. Suppose your local BBS was not acces- 
sible on the frequency that the node operates on. The 
BBS alias can be configured to provide easy access across 
other nodes to the BBS. Hence in the case of the Ipswich 
nodes, GB7MXM does not have a port on 144.650, but 
the node IPS2 on 144.650 can get to it by means of an- 
other node. If IPS2 is set to accept the extra aliases, 
and if BBSAlias is set to MXMBBS, then anyone who 
tries to uplink to MXMBBS would get GB7MXM. 
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Switch Commands 


TheNET X1 Quick Reference Guide 


Mode Parameters 


ACL [ { callsign + value } | { callsign - value } | { * value } ] # Min Max Function 

ALIAS [ * | new_alias ] 1 0 1 Hardware handshake host control mode 

ARP [ ipaddr [ { - ptel } | [+[ P ] ptel callsign [ DG | VC J) ] flag 

AUDIT [ number_from_0_to_255 ] ?) 0 3600 CWID repeat period ( seconds ) 

BBS [ callsign | * | ?] 3 4 10 CWID speed ( 10’s msecs per dot ) 

BBSALIAS { * | new_alias ] 4 0 3 Nodes broadcast channel enable flags 

BTEXT [ * | beacon_message_text ] where O0=none, 1=HDLC only, 2=RS232 

BYE only, 3=Both ports 

CALIBRATE [ period_value_from_1_to_60 [ toggle_value_1_to_period ] ] 5 0 3 Crosslink protocol selection 0=crosslink, 

CLOSEDOWN- a 1=KISS, 2=KISS+selcopy, 

CONNECT [ callsign [[V] digilist... ] 3=KISS+allcopy 

CQ { message_for_CQ_ packet ] 6 0 255 TX keyup delay ( 10’s of milliseconds ) 

CTEXT [ * | connect_message_text ] 7 0 1 Full duplex enable flag 

DXCLUSTER { callsign | * | ? ] DxC_alias [ * | new_alias ] 8 0 65535 RS232( port 1 ) node broadcast period 

HELP (secs ) 

HOST [ callsign | * | ? ] hostalias [ * | new_alias ] 9 0 3 Node broadcast algorithm control flags 

INFO [ sysop_set_message ] O=off, 2=RS232 port, 

IPADDRESS { new_IP_address ] 1 & 3 not normally used 

IPBROADCAST  [ new_IP_address ] 10 600 3600 Beacon interval ( seconds ) 

IPROUTE { ipaddr [ /bits ][- | {+ port [ ipgateway [ metric ] ] ] ] 11 0 2 Connect redirection to BBS flag 

IPSTATS [ {mewparam | *} {newparam | * }..... ] 12 0 31 Help messages enable flags 

LINKS 13 0 3 Hash node broadcast disable flags 

MANAGER (one bit per port ) 

MHEARD [ number_from_1_to_100 ] 14 0 1 Enable extra aliases monitoring if set 

MODE [ {new_param | *} {new_param | *}..... ] 

NODES {* [*] | call {+1-} ident qual count port neighbor [digis]] Audit Bits 

PARMS { {newparam | *} {newparam | *}..... ] Bit Function 

QUIT 0 Issue L1 stats every 10 minutes 

RESET [ any_character ] | Audit L2 connects & disconnects 

ROUTES [ port nodecall [ digilist ... ] {+ | -} pathquality ] 2 unused 

STATS 3 Audit L4 connects & disconnects 

SYSOP 4 Audit L7 use of sysop command 

TALK [ text_to_send ] 5 Audit all L7 switch commands 

UI dest string_of_text_to_be_sent_in_UI_frame users 6 Issue CPU stats every 10 minutes 

notes i unused 

Any command may be enabled or disabled by the use of the ‘+’ or ~’ modifier, as ACL Bits 

shown below : Bit Function 

ANY_COMMAND[ + | - | that_command's_parameters ] 0 Bar all incoming L2 connects 

IP addresses are of the form nnn.nnn.nnn.nnn where nnn is a number 0..255 1 Bar outgoing L2 downlinks 

IProute port paramter takes the form 0 or 1 for radio or rs232 AX.25 2 Ignore nodes broadcasts 

or N for Net/Rom 3 Bar gatewaying at level 3 

ARP ptcl parameter is AX.25 or Net/Rom ( may be abbreviated ) 4 Bar incoming L4 connects 
5 Bar outgoing L4 connects 
6 ignore SSID in searching 
7 unused 

PARMS PARAMETERS IPSTAT Parameters 

# Min Max Function # Min Max Function 

1 1 400 Maximum number of destination nodes 1 0 3 ip L2 AX.25 Modes ( 1 bit per port, 1=DG ) 

2 0 255 Minimum quality for auto update 2 0 1 ip Forwarding, 1=enable router, 0=disable 

3 0 255 HDLC ( radio, port 0 ) default quality 3 2 255 ip Default TTL 

4 0 255 RS232 ( crosslink, port 1 ) default quality 4 0 0 ip In Receives 

5 0 255 Initial value for obsolescence counter 5 0 0 ip In Header Errors 

6 1 255 Minimum obsolescence for node broadcast 6* 0 0 ip In Address Errors 

7 0 65535 Auto update broadcast interval ( seconds ) 7 0 0 ip Forwarded Datagrams 

8 0 255 Level 3 ( network ) Time To Live Initialiser 8 0 0 ip In Unknown Protocols 

9 5 600 Level 4 ( transport ) timeout ( seconds ) hate 0 ip In Discards ( TTL exceeded ) 

10s 127 Level 4 ( transport ) retries pA postal 0 ip In Delivers 

112441 60 Level 4 ( transport ) acknowledge delay ( seconds ) Lieve *U ip Output Requests 

1290.1 1000 Level 4 ( transport ) busy delay ( seconds ) 12* 0 0 ip Output Discards 

13 1 127 Level 4 ( transport ) window size ( frames ) 1370 0 ip Output No Routes 

14° 127 Level 4 ( transport ) congestion control threshold DA oe oh 30 ip Reasm Timeout 

15 0 65535 Level 7 ( switch ) inactivity timeout ( seconds ) 15* 0 0 ip Reasm Requireds 

16 0 255 Persistance for transmit delay 1670 0 ip Reasm OKs 

17 pan i2e Persistance slottime delay ( 10’s of milliseconds ) 17e 0 0 ip Reasm Fails 

Bread ated Level 2 (link ) T1 timeout, ie FRACK ( seconds ) 18, FADS ip Frag OKs 

19)°-*7 7 Level 2 ( link ) window size ( packets ) ioe 0 ip Frag Fails 

20.01 UGA27 Level 2 ( link ) retries 20 0 O ip Frag Creates 

21 0 6000 Level 2 ( link ) T2 timeout ( 10’s of milliseconds ) Those marked “ are not used in this version 

22 0 65535 —_ Level 2 ( link ) T3 timeout ( 10’s of milliseconds ) 

23 0 1 Level 2 ( link ) digipeat enable flag Host Escape Commands 

24 0 1 Callsign validation flag <escape> C Connect to TheNET node 

25 0 2 Node beacon control (0=off, 1=only if active, 2=always) <escape> D Disconnected 

26 0 1 CQ broadcasts enable flag <escape> P [ new_password ] 
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Glossary of Packet Networking Terms 


This is a glossary of all of the words that | could discover were in common use in packet radio. Mostly as this book was put together 


each time | or one of the many prooftreaders (hank youl) came up with a word that was not detined, and yet was not part of 3th 


grade ham radioish, it was added and | wrote a definition for it Much of this is based on my own knowledge and may be in doubt. 


Do not hesitate to verify any of this information (as usual) and send me corrections, missing words, better definitions ete etc. 


-Tadd KAZDEW 


AFSK 

Amiga 
Autoforward 
Autorouting 
AX.25 

Backbone 
Backoff 

Baud 

BBS 

Beam 

Breakout Node 
Callbook Server 
Carriage Return 
Choke/Unchoke 
Circuit 

Collision 
Commodore 64 
Control character 
Converse Node 
Coverage 
CROWD 

CSMA 
Dedicated port 
Digipeater 
Diode Matrix 
Disk Drive 
DOVE 
DxCluster 
Dynamic Rerouting 
EOC 


EPROM 
ERS 

False Route 
F.E.M.A. 
Flat Network 
Floppy Disk 
Forward 
Forward File 
FRACK 


G8BPQ Code 
Gateway 
HexiPus™ 
Hard Disk 
Host Mode 


Internet 

KISS 

LAN 

Locked Node 
Locked Route 
Macintosh 
Mail Drop 
Matrix 

Matrix Monitor 
Multistreaming 
NAPRA 


NBOD 
NEDA 
Neighbor 
Node 

Node Broadcasts 
NOS 
Octopus 
OEM 
Packet 
Parameters 
PARMS 


PMS 

Point to Point Link 
Poll Packet 

Port 

PROM 

Protected Backbone 
Protocol 

Quality 

RAM 

Real Time 
Redundancy Path 
Response Time 
RETRY 

Reverse Forward 
ROSE 


Route Stepping 

Routing Loop 

RS-232 

Serial Port & Serial 
Communications 

Server 

Site Hardening 

Site Manager 

Site Sponsor 

Site Sysop 


TOPIP 

Terminal 

Time To Live 

TheNET 

TheNET PARMS 

Three Way Wireline Link 
Throughput 

TINK 


Unproto 

User Channel 
WAN 

Wireline Link 
Wink ‘N Blink Mod 
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AFSK 


Audio Frequency Shift Keying. This is a mechanism for 
sending digital information over a radio. A signal 0 is 
sent using one tone while the signal 1 is sent using a 
different tone. This is the mechanism used by telephone 
modems and packet radio modems. 

Amiga 

Perhaps the best of the personal computers available 
in the hobbyist price class the Amiga has seen terrible 
sales and lousy acceptance by the business and hobby 
computer community. It is most likely that this is be- 
cause of Commodore's poor marketing and the excellent 
marketing efforts of Apple Computer and IBM. The 
Amiga does not have very high acceptance in the amateur 
radio community either. If you are shopping for a 
computer you will want to check these out, however. Most 
varieties of amateur radio programming are available 
on the Amiga. Hams who own Amigas tend to be ex- 
tremely supportive of new owners of Amigas. Programs 
available for the Amiga include Satellite tracking, TCP/ 
IP, AX.25 terminal programs, educational and technical 
programming. (See also Macintosh and PC) 


Autoforward 


Many of the bulletin board and mail server programs 
(BBS) are capable of passing messages to each other. 
The process of a bulletin board recognizing that it has 
mail to go to another bulletin board, connecting to another 
board and then sending the traffic is called Autofor- 
warding. (See also Forward File) This allows packet 
users to send mail in anon real time fashion anywhere 
on the planet where compatible BBSs exist. 


Autorouting 


This is a process by which a network node can pass traffic 
to another node via one or more intermediate nodes. 


AX.25 


This is the designation for the protocol used by TNCs 
to talk to one another. (See Protocol) 


Backbone 

A backbone is a system of links where nodes may 
communicate without interfering with or being interfered 
with by local access, and where data may be passed in 
a fashion and with hardware that is optimized for passing 
data, rather than optimized for inexpensive user stations. 


Example: 
¢ Most user stations operate at 1200 baud on 2 
meters. A backbone would be more efficient and 
less susceptible to interference if it were on UHF 
or 220. Also a backbone might be optimized by 
taking advantage of the knowledge of all radios 
on each link. Such optimization might included 
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setting acknowledge delay (RESPTIME), Trans- 
mit lead time (TXDelay) or persistence (PPersist) 
to values that work best for the radios on the 
backbone frequency. Such settings might be 
impossible if any average user stations were to 
be able to access the link radios. In addition baud 
rates might be increased if only a few radios/[NCs 
need be affected. 


Backoff 


When a packet is sent and not responded to, the send- 
ing station will wait a specified ‘backoff before retrying. 
In simpler systems this is called “FRACK” or FRame 
ACKnowledge delay. In more complex systems, like TCP/ 
IP, the backoff time can be calculated based on previ- 
ous performance of the link. One such backoff proce- 
dure is called exponential backoff. In this system the 
amount of time delayed between resending a missed 
packet increases by a stable factor each time the packet 
is tried, until some maximum backoff time is reached. 
(See TCP/IP, Retry) 


Baud 


Baud is a measure of data flow. One baud indicates one 
transition of data. 1200 bauds indicates 1200 transi- 
tions. In packet radio one character of text equals 8 bits 
of information. 8 bits of information requires 8 transi- 
tions of the modem tones. That means that there will 
be about 150 characters of data in one second of 1200 
baud transmission except for the fact that packet 
transmissions include key up time and callsign infor- 
mation which take up many characters of time. 


BBS 


Bulletin Board System. This is a server which is accessed 
by packet stations to be a repository for messages and 
files. Those messages and files can be accessed by all 
packeteers who connect to the BBS, if desired. BBSs 
also have a capability called Forwarding which may be 
used to send files between BBSs. (See AutoForward) 


Beam 


A directional antenna. Beams are usually made of 
aluminum and are constructed from a horizontal length 
of tubing and between 4 and 16 1/2wave length alumi- 
num elements. Beams for packet radio usually cost 
between $50 and $100. The key features of a beam are 
1. Directionality and 2. gain. In this case gain means 
that because less power and signal is wasted in the di- 
rection the beam isn't aimed at, it is used in the direc- 
tion the beam is aimed at. See the ARRL Handbook for 
more information on antennas. 
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Breakout Node 

This is a node that is capable of handling many links. 
In many cases packet nodes have been installed in places 
where many radios or backbone links are not allowed, 
such as on high mountains of great commercial value. 
A breakout node holds no special meaning except that 
it is a node that has proven to be very expandable and 
at which the node owner sees little or no limitations on 
reconfiguration. 


Callbook Server 


This is a network server whose function is to allow 
stations to access, in real time, callbook information. 
These servers are operated both stand-alone and as part 
of DxClusters. See the server listing in your Dedicated 
Link. 


Carriage Return 

On a mechanical typewriter the motion of pushing the 
carriage, which held the paper, to the left all the way 
until it stops is called a carriage return. When electric 
typewriters came into existence there was a particular 
button on the keyboard, at the right hand end of the 
typewriter keys marked J, K, L, ;, ', which was called 
the return key or carriage return key. On modern 
computer keyboards that key still exists and is either 
left unmarked or is labeled enter, return, carriage re- 
turn, or -!. The function of the carriage return key is 
to instruct the computer or remote device that the end 
of a line has been reached. On a terminal or computer 
emulating a terminal when the carriage return is pressed 
the binary number 00001101 is generated. The symbol 
used to describe a carriage return is sometimes “M which 
means control M. This number is also represented as 
OD hex or 13 decimal. (See control character) 


Choke/Unchoke 


When a computer is unable to process data as fast as 
another computer is sending it the receiving computer 
may instruct the sending computer to stop sending the 
data. This condition is often referred to in the packet 
world as ‘choke’. ‘Unchoke’ refers to the re-enabling of 
the sending computer. 
Example: 
¢ ATNC running TheNET is capable of storing a 
fixed number of packet frames in memory. If this 
number gets exceeded data might be lost. Because 
each TheNET node is capable of supporting many 
users and some other network management 
functions simultaneously the memory is parti- 
tioned to smaller blocks called buffers. Each user 
on the node is allowed four buffers (in the rec- 
ommended network). When those four buffers 
are used up the TheNET TNC attempts to choke 
the user. If the TheNET TNC is at the far end 
of a network circuit the choking and unchoking 
process takes somewhat longer. What actually 
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happens is that when a message is passed across 
the network to the destination user port that 
destination user port may respond with a ‘choke’ 
message. The destination user port will attempt 
to deliver the data that is has and when it is ready 
will send an unchoke message back to the origi- 
nating user port. Based on a time-out timer the 
originating user port might resend it’s delayed 
packet even though it has not received the un- 
choke message. 
Circuit 
In a TheNET network a circuit is an assigned connec- 
tion between two nodes. Each of the two nodes has in- 
formation to the effect that the circuit exists. The two 
nodes also have a routing table from which the first el- 
ement on the path to the other node may be realized but 
the two nodes do not know all of the intervening nodes. 
The circuit exists until the destination user or server or 
the originating user or server disconnects, or until one 
of the two nodes decides that data cannot be sent any 
more (due to L3 retry time-out or unchoke failure) or if 
no data is passed across the circuit during the time set 
by the no activity time-out. In the recommended network 
the L3 retry time-out is 5 minutes times 2 retries and 
the no activity time-out is two hours. (See neighbor, 


choke / unchoke) 


Collision 

This is an event where a receiving station doesn’t re- 
ceive it’s desired packet because another packet was 
generated by a different packet station in the same time 
frame as the desired packet and interference occurs. In 
this case the sending station will wait a backoff time and 
the packet is retried or a special poll packet is gener- 
ated. (See backoff, poll-packet, retry) 
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Commodore 64 

Back in the late 70s, before everybody had their own 
computer, Commodore was one of the companies that 
cranked out a real cheapy for the purpose of grabbing 
a piece of the very lucrative extremely low budget com- 
puter market. They were successful. The Commodore 
64 is the only one of those 1970s low budget computers 
that is still popular. Others include the TI99 and ZX81. 
The Commodore 64 is a computer in a keyboard. The 
entire computer guts are located inside the plastic case 
which looks like an ordinary keyboard. Enclosed in the 
box are 64K of memory (equivalent to 64000 characters 
of text) which is relatively small compared to the 1000s 
of K of memory found in modern PC compatibles, Macin- 
tosh and Amiga models. The software for the Commo- 
dore 64 is usually built into accessories that plug into 
an expansion slot, or available on cassette tape. 

The Commodore 64, unlike the Macintosh, Apple 2, and 
PC compatible, often uses a normal television set for a 
video display. Even with the optional (and rather ex- 
pensive) computer monitor display the Commodore only 
gets about 40 characters of text across the screen and 
about 16 lines of text. This is as compared to 80 char- 
acters by 25 lines for the cheapest of PC compatibles, 
or to about 128 characters by 43 lines for more modern 
models. For packet radio 80 characters is the standard 
line length so 40 characters is a handicap. 

There is a disk drive made for the Commodore 64. It 
actually sold for several times the cost of the computer! 
Since the Commodore 64 is often found as a throw-away 
or dug out of someone's basement the disk drives can 
be found for free as well. The highest reasonable price 
paid for a Commodore 64 including the disk drive is 
probably in the vicinity of $100. This is one of the things 
that makes the Commodore 64 an astoundingly popu- 
lar amateur radio accessory. 


Control character 


On all keyboards which meet the American Standard 
Code for Information Interchange (ASCID standard there 
is a key marked as Ctl, Cntrl, Ctrl or Control. This key 
is a shift key. That means that when that key is pressed 
the values associated with other keys are changed. Now 
when a normal alphabet key is pressed the control value 
of that key is sent, instead of the normal alphabet value. 
The control value is called the control character. Ex- 
ample: Ifthe control key is pressed and an A is pressed 
the keyboard (or computer) will generate a control A. 
This is also described in text as a ‘A. There are actu- 
ally 32 control characters, “A through “Z and six oth- 
ers. The control characters are interpreted by comput- 
ers as ASCII defined functions. For instance, “M is the 
same as a carriage return. “C is used by most computers 
to mean stop, or go to command override mode. (See 
carriage return) 
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Converse Node 
See CROWD 


Coverage 


The area in which a signal can be heard is that signal's 

coverage. Usually coverage refers to both transmit and 

receive. If a station can both talk to and receive from a 

station in a particular area that station has coverage in 

that particular area. Wide area coverage means that 

the station can be heard and can hear a wide area. If 
a station can be heard in an area that it can't hear from 

then there are problems. Certain derogatory words have 
been used to describe those problems, like alligator 

(mouth, no ears). 


CROWD 

This is the name given by the NEDA founders for a piece 
of software written by NORD><LINK to run in a 
TheNET network. Most NORD><LINK documentation 
refers to this is a mini-conf (conference) node. The 
CROWD software is installed at a TNC. Access is over 
the network only, through the serial port in the CROWD 
TNC from other TNCs at the same node site. 


CSMA 


Carrier Sense, Multiple Access: This is a system of packet 
operation that requires that all stations wait for the 
channel to be quite before transmitting. Most amateur 
radio packet uses CSMA. 


Dedicated port 

This is a port designated for a specific purpose with only 
one other station on the frequency, usually a tie-in to a 
server or other network hardware. 


Digipeater 

A TNC used for relaying messages on a single frequency. 
Digipeater functionality is built into all user TNCs. A 
digipeater is used for sending a message beyond the range 
of a user station. Normally if there are two stations that 
want to communicate beyond their own range they will 
use a digipeater in between. One detail with digipeat- 
ers is that they do not recognize when a message they 
have relayed does not get through. It is up to the sending 
station to retransmit. Digipeaters are inherently sus- 
ceptible to hidden transmitter syndrome. NAPRA rec- 
ommends against digipeating in any form except in 
emergencies. 


Diode Matrix 

The TNCs running ROSE or TheNET network software 
can communicate to each other over their RS-232 ports. 
If two TNCs are used at a node site the connections are 
simple connector to connector wire connections. If more 
than two TNCs are used a diode matrix is required. (See 
HexiPus™) 
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Disk Drive 


A disk drive is a computer accessory that stores data 
in the form of magnetic impulses on a flat media that 
is much like an extremely high quality magnetic record- 
ing tape. The media is on a spinning platter, like a pho- 
nograph, and is read and written by a tape head that 
moves across the media, like a phonograph. The me- 
dia is of two basic qualities and is called floppy or hard. 
Floppy media is low tolerance, meaning that if the me- 
dia is dented or dirty it should still work. Floppy me- 
dia can store about 200,000 characters of data per square 
inch. Most floppies store less than that. The rate at 
which data can be read or written to a floppy drive is 
usually less than 30,000 characters of data per second. 
Floppy media is always exchangable. You can change 
out the floppy in the disk drive quickly. Floppy media 
is commonly used for transfer of information between 
computers and for storage of seldom used programs. On 
really low budget computer systems floppy media may 
be the only non-volitile (not erased when power is re- 
moved) memory that the computer has. Floppies are 
commonly seen in two different sizes, 3.5" and 5.25". 3.5" 
floppy media is sealed inside a plastic cartridge which 
is flat and square. There is a little access door which 
covers the media when it is not inserted into the floppy 
drive. This is commonly called a 3.5" floppy disk. Me- 
dia sizes depend on the way the data is stored on the 
floppy disk and usually range from 360K (360,000) to 
1.44M (1,440,000) characters. 5.25" floppies are jack- 
eted by a thin plastic cover which doesn't entirely cover 
the magnetic media. They are commonly stored with 
a paper slip over the exposed parts. Media sizes range 
from 80K to 1.2Mbytes. 

Hard media is high tolerance. Getting dirt on the me- 
dia will destroy it. Normally (although not 100% the 
case) hard media is sealed into the disk drive with the 
read/write tape head. Hard media is commonly used 
for storage of a computer's operating system, applica- 
tions programs, and temporary data. Hard media can 
store as much as 1,000,000,000 characters of data per 
square inch. Access time to that data can be as fast as 
a hundredth of a second and the data can be read off 
the disk at millions of characters per second. In order 
to get that much data on so small an area the record- 
ing surface has to be very flat and in order to get the 
data on and off the disk so fast the disk has to spin very 
fast. 


DOVE 


An OSCAR satellite (OSCAR 17) whose full name is 
Digital Orbiting Voice Encoder. 
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DxCluster 


A server used by HF operators to pass information about 
contacts. This software, originally written by AK1A, also 
operates as a database of HF related information. One 
key feature of the DxCluster software is that DxClus- 
ters may share contact information (called Dx Spots) in 
real time. That is that one station connected to one Dx- 
Cluster may introduce a Dx Spot report which will then 
be shared by all of the stations connected to all of the 
DxClusters which are networked together. See the server 
listing in your Dedicated Link. 


Dynamic Rerouting 

In a network where redundancy exists in the backbones 
from one city to another some types of network software 
allow for the network to recover automatically from a 
backbone hardware failure by rerouting traffic through 
the redundant link. This is called ‘dynamic rerouting’ 
as it can adjust dynamically to a changing network. (See 
ROSE, TCP/IP) 


EOC 


Emergency Operations Center. This is a term used by 
some state governments for a state or county government 
owned facility at which emergency services radio 
equipment and other gear is clustered. Some E.O.C. 
facilities are located in bomb shelters, others in build- 
ings as part of a state office complex. A good packet net- 
work would include an on line TNC or BBS at every 
E.0.C. in the network's region. (See OFM) 


EPROM 


Erasable Programmable Read Only Memory. This is 
an integrated circuit (IC) which is used in computers, 
including TNCs, to permanently hold a computer pro- 
gram. In PC compatibles and Macintoshes EPROMs are 
used to hold the boot program. That's the program which 
is responsible for loading the operating system into the 
computer from a hard disk or floppy disk. In TNCs all 
of the program is located in one EPROM. EPROMs are 
erasable using ultraviolet light for between 2 and 40 
minutes. Thus EPROMs have a small lens in the middle 
of the top which exposes the internal electronics. Dur- 
ing long term usage EPROMs are covered with a piece 
of opaque tape. EPROMs cost about 50¢ surplus and 
about $5.00 new. The EPROM used for TheNET is called 
a 27C256 or a 27256 (either is ok). EPROMs can be 
programmed using a peripheral to a PC called an 
EPROM programmer which costs about $150 from JDR 
Microdevices @1-800-538-5000. 
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ERS 

Exposed Receiver Syndrome: This is a condition where 
a packet station, be it node or user, is unable to trans- 
mit due to the fact that it perceives the channel as be- 
ing active continuously. This can be caused by Hidden 
Transmitter Syndrome and is often the case when a node 
is located on a high hill with surrounding metro areas. 
(See HTS, CSMA) Also see an article in this Quarterly 
called Exposed Receiver Syndrome. 


False Route 


In a network using TheNET software the node routing 
is generated automatically by the nodes themselves. If 
improperly managed it is quite possible for routing to 
be discovered and used by the nodes such that Dx paths 
are treated as real paths. In this case a route may be 
created in the routing table that depends on a ‘lift’ 
(propagation enhancement) condition. When the lift goes 
away the nodes will be helplessly trying the ‘false route’. 
This condition is preventable in a TheNET system by 
manually controlling the route tables to specify valid 
routes to neighbor nodes. This situation cannot occur 
with ROSE or TCP/IP software as all neighbor nodes 
and routing information is created either manually or 
by software that is much more intelligent than TheNET. 
(See TheNET, locked route, ROSE, TCP/IP, neighbor). 


F.E.M.A. 


Federal Emergency Management Agency. These are the 
guys with megabucks to spend on your networking 
project. FEMA is very interested in seeing a non-gov- 
ernment owned and maintained network of interstate 
packet equipment. Don't wait for F.E.M.A. money but 
F.E.M.A. can make life easier if they are impressed with 
what we can do with networks. They've been known 
to drop words on other government agencies like forest 
departments etc. 


Flat Network 


A flat network is a system of dual port nodes where 
one of the ports is a backbone port. All backbone ports 
in the network are on the same frequency and may not 
be hidden transmitter free. It is said to be flat because 
the network topology is flat. Flat backbone ports are 
defined here so a node builder constructing a system per 
these specifications can have an access to or from an 
existing flat network. A flat backbone port is not on 2 
meters or HF. This port specification is also used where 
the other stations on frequency are not able to operate 
with respect given to Hidden Transmitter Syndrome or 
if locked routes and connect disable are not used on all 
adjacent nodes. (See selective neighbor routing in Net- 
working Around HTS in the TheNET Resource Manual) 


Floppy Disk 
See Disk Drive 


Forward 
See Autoforward. 
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Forward File 

This is the disk file on a packet bulletin board system 
(PBBS) that is responsible for directing the autoforward- 
ing operation. By making entries in this file the PBBS 
system may select what packet paths are used to each 
PBBS that is forwarded to, when each operation is per- 
formed and what traffic is sent during each piece of the 
forwarding operation. (See autoforward) 


FRACK 

FRame ACKnowledge delay: This is the time after a 
packet is transmitted by a TNC before the TNC decides 
that a frame acknowledge is not going to occur. At that 
point the TNC performs backoff (some TNCs + TCP/IP) 
and a retry. (See backoff, retry). 


Frame 


A frame, or packet frame, is a single packet. Several 
frames may be sent in one transmission but each has 
it's own address, start and stop. 


FTP 


File Transport Protocol. This is a part of TCP/IP which 
allows a user of a TCP/IP host to request or send files 
from other TCP/IP hosts. 


G8BPQ Code 

John Wiseman, G8BPQ, developed a TSR (terminate stay 
resident) program for the IBM PC and compatibles that 
would imitate TheNET and allow node access for a 
program that runs on the PC. This program simulates 
the TheNET node functionality and allows routing from 
a TheNET system directly to the PBBS or other program 
running on the PC. Unlike a TheNET node which can 
only handle one radio per TNC, the G8BPQ program may 
direct traffic in and out of several radios by using KISS 
TNCs or other TNC/modem cards. (See KISS, Dedicated 
port, Locked node) 


Gateway 

A configuration of nodes where connectability is avail- 
able by deliberate manipulation but where automatic 
end-to-end routing is not possible. This is useful for 
connecting two networks together such that users and 
servers on one network can access users and servers on 
the other network without compromising networking 
practices on either network. 


Examples: 

¢ To access packet radio from Fred’s telephone packet 
gateway I can phone up and use a password. After 
Fred’s machine accepts the password I can use my 
callsign on Fred’s PC. 

¢ To gateway into TCP/IP in Seattle from Porland I 
can use the TheNET network by connecting into 
OARS which is a PC running NOS. Once I get con- 
nected I can use the TELNET program to access 
another TCPer. OARS is a gateway. 


N.A.P.R.A. Notebook v1.0 
© NAPRA 1992 


HexiPus™ 

Six way diode matrix card: This is a product of the North 
East Digital Association (developed by WB2JLR) that 
allows up to six TNCs to communicate via RS-232. This 
is used in TheNET and ROSE multiport nodes such that 
up to 6 radios may be installed at a single network node 
site. More than six radios/TNCs may be used by add- 
ing more than one HexiPus™ and by using a wireline 
link based on a TNC at each HexiPus™. (See wireline 
link, diode matrix) 


Hard Disk 
See Disk Drive 


Host Mode 


WB8DED created a software package for the TAPR TNC 
1 that was called Host Mode. This package was later 
created for TNC 2. Some BBS programs took advan- 
tage of the command language in Host Mode to control 
the TNC and to allow multiple users to connect to the 
BBS at the same time. AA4RE BBS may have been the 
first software to use this feature. TheNET incorporates 
a very small subset of the Host Mode command set. 

Host Mode is used to refer to the condition where a node 
has a CRT terminal or computer plugged into it that will 
be used in ASCII mode (not using networking protocol). 


HTS 


Hidden Transmitter Syndrome: This describes a con- 
dition where throughput is drastically reduced to well 
below the specified baud rate because a single station 
is able to hear two or more stations that can’t hear each 
other. (See throughput) 


HTS free 


By making sure that every radio/TNC on a frequency 
can hear every other radio/INC most of the collision 
problems and inherent loss of throughput may be re- 
moved. At this point backoff becomes effective and the 
performance of the system of radio/TNCs may be pre- 
dicted more accurately. The only remaining problems 
occur when radio dead time due to slow transmit receive 
switching is excessive. Also backoff must be used if there 
are more than two radio/TNC sets on frequency. (See 
backoff) 


Internet 


The Internet is a public system of computers which com- 
municate over commercial lines (usually telephone or 
leased telephone lines) using TCP/IP. Usage of the In- 
ternet network is free. Usage of the computers that are 
hooked to the Internet is not necessarily free. Most people 
who have access to the Internet either pay a fee or have 
connection to the network from work or school. There 
is a book on the subject called Internetworking with TCP/ 
IP by Douglas Comer and published by Prentice Hall. 
You should read this if you are interested in the details. 
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KISS 


Keep It Simple Stupid: In the packet world this usually 
refers to a program or mode that relates to TNCs in which 
the functionality of a TNC is entirely remote controlled 
by an external PC or other host. KISS mode is used by 
G8BPQ code and TCP/IP. 


LAN 
Local Area Network: NAPRA defines a LAN as a user 
access node and a group of users. Servers do not com- 
municate with the network on the LAN frequency but 
use dedicated access frequencies. LAN users which are 
home stations running minimum antenna and power 
configurations to access the node may access multiple 
servers through the network via the local access node. 
Example: 
¢ A sample network node setup would include a 
user port that can hear twenty or less active 
packeteers. No other user ports and no servers 
share the frequency within the range of the user 
port radio. The node setup must included one 
or more backbone links to other nodes. If any 
servers exist in the area that need network ac- 
cess then dedicated link radios and TNCs are 
added to the node stack. Users may access those 
servers (if any user services are supplied) from 
the LAN frequency by using TheNET, ROSE or 
other networking technology. 


Locked Node 

TheNET nodes have the capacity to generate routing lists 
automatically based on parameters set in the node’s 
RAM. The parameters specify default quality values to 
be assigned to routes to each neighbor, separately de- 
fined for radio port neighbors and RS-232 port neigh- 
bors. If a neighbor tells me (I’m a node now) about a 
certain node, by callsign and node name and quality, I'll 
remember it for a duration that is also setable by the 
parameters in RAM. If that duration ends and I haven't 
gotten a refresh on that information, I'll forget about the 
node. A locked node is where an individual node is given 
a specific quality and nearest neighbor route, but for 
which the duration is set to infinite. This locked node 
must be manually entered by a sysop but is visible to 
anybody who wants to look for it by doing a N NODE- 
NAME for any nodes that are suspected as being locked. 
A locked node may be used to make sure that a node 
listing doesn't go away, to set a node in with a route that 
is different than which may be automatically generated, 
to set a node in with a quality which is less than that 
which is automatically generated, or to make a node not 
show up at all. The last is difficult to do and no longer 
necessary with the advent of the ROUTE 2 command. 
(See Sysop Commands, part of the TheNET Resource 
Manual in this Document) 
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Locked Route 

TheNET nodes have the capacity to generate routing lists 
automatically based on parameters set in the node’s 
RAM. The parameters specify default quality values to 
be assigned to routes to each neighbor, separately de- 
fined for radio port neighbors and RS-232 port neigh- 
bors. It is possible using the sysop's ROUTE command 
to manually set a route at a specified quality. This may 
be done so that the routes never change due to weather 
induced radio performance effects, due to accident or due 
to malicious intent by another party. 


Macintosh 


A personal computer which is a product of Apple Cor- 
poration. A Macintosh is a windows oriented computer 
which is not compatible with IBM's PC. The Macintosh 
is best known for being simple to learn and very visual 
oriented. Most programs available for amateur radio 
are written for IBM PCs and so the Macintosh is not 
as popular for hams as the IBM PC compatible. On the 
other hand the programs that are available for the 
Macintosh tend to be so much easier for a non computer 
person to learn that Macintosh computers have a larger 
user base in ham radio than would seem likely by mere 
utility. (See PC). 


Mail Drop 

A part of a TNC program that allows messages to be 
loaded into the TNC and then retrieved from over the 
air or from the terminal at the TNC. Mail Drop is what 
AEA calls this function. It is also called PMS or Per- 
sonal Message System, by PacComm. 


Matrix 

Matrix = Diode Matrix: The TNCs running ROSE or 
TheNET network software can communicate to each 
other over their RS-232 ports. If two TNCs are used at 
a node site the connections are simple connector to 
connector wire connections. If more than two TNCs are 
used a diode matrix is required. (See HexiPus™) 


Matrix Monitor 

Communications between TheNET TNCs via the RS- 
232 port or over a matrix is not in a textual format that 
is readable by a dumb terminal or protocol analyzer. A 
Matrix Monitor is a hardware or software device that 
can display the data passing across the matrix in a form 
that is legible and informative. G8BPQ code includes 
a program that can observe TheNET communications 
over the matrix. KA2DEW developed a crude single 
board computer with this capability also but the prod- 
uct was never made reproducible. (Anybody want a good 
project?) 


Multistreaming 


This is the process by which a user can connects to several 
stations at once. (See Stream) 
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NAPRA 


Northwest Amateur Packet Radio Association: This is 
an Association founded in 1983 to promote packet radio 
in the north west region of the United States. 


NBOD 
NAPRA Board Of Directors: This is the term used to refer 
to the board of directors and appointees of NAPRA. 


NEDA 

The North East Digital Association. This is an Asso- 
ciation that was formed in the fall of 1989 to support 
and instigate packet network development in the north 
east region of the US and Canada. The contact address 
is Box 563 Manchester NH 03105, or via packet is NEDA 
@ WB2QBQ.ny. 


Neighbor 
In a network of nodes the neighbor of a node is any node 
that is talked to directly. 


Example: 
e Ifa linked system consists of FRED <-> BOB 
<-> ED <-> LEFT <-> RIGHT then the neigh- 
bors of ED are BOB and LEFT 


Node 

A node is an active element in a network. This can mean 
anything from a user station to a bulletin board. Tra- 
ditionally a node in packet radio is an intelligent router 
of real time data, somewhat more intelligent than a di- 
gipeater but faster than a store and forward BBS. 


Node Broadcasts 

Each node sends a one way message out every half hour 
(setable) that tells it's neighbors what nodes are listed 
in the nodes table. The neighbor TheNET nodes inter- 
pret this information based on a factor called quality. 
(See Nodes Broadcasts which is part of Theory of Op- 
eration in the Resource Manual part of this Notebook) 


NOS 


Network Operating System. NOS is a program which 
is generally used to communicate using the TCP/IP 
protocols but which actually is much more than just a 
program that does TCP/IP. NOS runs on a personal 
computer and. NOS is the name used to describe doz- 
ens of different programs which are all similar and which 
all are used for TCP/IP but which have huge differences 
in look and feel and features supported. NOS exists for 
most hard-disk based personal computers. 
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Octopus 

This is a product of John Painter-NONDO (rights now 
owned by NEDA) that is an 8 port diode matrix card 
which couples TNC2 compatible TNCs to make a mul- 
tiport node stack. This product has been outdated by 
the HexiPus™. (See HexiPus™, Diode matrix) 


OEM 


Office of Emergency Management. This is a term used — 


by some state governments for a state or county gov- 
ernment owned facility at which emergency services radio 
equipment and other gear is clustered. Some O.E.M. 
facilities are located in bomb shelters, others in build- 
ings as part of a state office complex. A good packet 
network would include an on line TNC or BBS at ev- 
ery O.E.M. in the network's region. (See EOC) 


Packet 

A packet is a block of many characters (or bytes) which 
are sent together along with a few extra characters 
(checksum) used to guarantee that the data is completely 
error free. The packet includes addressing information 
so that the receiving station knows that the packet is 
for it as well as who sent the packet. 


Parameters 

In TheNET software there is a list of values used by a 
TheNET node to configure options. These values are 
called parameters or PARMS. (See Parameters, in the 
TheNET Resource Manual) 


PARMS 


Abbreviation for parameters. In TheNET software there 
is a list of values used by a TheNET node to configure 
options. These values are called parameters or PARMS. 
(See Parameters, in the TheNET Resource Manual) 


Path 


This word is used to mean the nodes, digis and servers 
that must be used to pass data from one point to another. 
Sometimes the path may be specified without including 
some intermediate nodes if the knowledge of those nodes 
is not necessary to pass the data or make a connection. 


PBBS 


Either Personal Bulletin Board System or Packet Bul- 
letin Board System. The former is called personal mail 
drop or personal mail system (PMS) to avoid confusion. 
PMS indicate a mail box that is contained inside a normal 
user TNC. Packet Bulletin Board Systems are referred 
to as BBS usually. (See BBS.) 


PC 


Personal Computer. Usually refers to a computer that 
is identical in function to a product by IBM that was 
marketed as an IBM PC. They are more correctly re- 
ferred to as IBM compatible PC. PC could mean any kind 
of computer that is used by an individual for general 


purposes (i.e. not a microwave oven control panel). It 
is sometimes hard to determine if a person who men- 
tions PC is referring to a generic personal computer (i.e. 
Macintosh, Amiga, IBM PC, Atari etc..) or a specific 
meaning an IBM PC compatible. In the Notebook we'll 
try to be real careful and refer to all JBM compatible PCs 
as PC compatibles or IBM clones. 

The PC compatible is the hardest of the popular personal 
computers to learn, the least expensive for the proces- 
sor and display performance you get, and the most 
supported with technical software. There are dozens of 
choices for packet radio software available for the PC 
compatible. There are even several different custom 
hardware products that let you have a TNC built into 
the PC compatible. The cheapest method of creating your 
own TheNET proms is also based on a PC compatible 
and a plug in hardware card. (See Macintosh, Amiga) 


PMS 


Personal Mail System. This is a program that resides 
in anormal TNC. It usually is included with the TNC 
as a standard feature when it is bought. The program 
allows the user of the station, or hams connecting over 
the radio to leave mail that can be picked up either lo- 
cally or remotely. Some incorporate the ability to re- 
verse forward. (See forward, reverse forward) 


Point to Point Link 


This is a radio path between two sites on a frequency 
where there will only be two radios within range. Nei- 
ther radio may hear any other radios except the other 
end of the link. If these conditions are met packet data 
may travel across the link at the absolute highest 
throughput possible for a packet link using the provided 
equipment. A point to point link is much faster (by sev- 
eral times) than any other kind of link architecture us- 
ing the same class equipment. This is because there will 
be no delays caused by collisions. A point to point link 
is much more efficient, in terms of spectrum usage, than 
any other link architecture. This is because directional 
antennas may be used and power may be minimised at 
each end of the link. 

Note that the fact that a link is a point to point link 
does not specify what kind of data is being passed or what 
baud rate the link is running. Point to point links may 
be used for server to server, server to network, network 
to network or user to network communications. 

In a TheNET network point to point links should be 
used for all node to node backbones or trunks. For 
mapping purposes the specification Point to Point Link 
is only used if both stations indicate that they will be 
the only two stations on that frequency. This specifi- 
cation implies the use of selective neighbor routing. 

(See also the section titled Networking Around HTS 
in the TheNET Plus Resource Manual) 
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Poll Packet 

In the latest version of AX.25 packet protocol if a trans- 
mitted information packet is not acknowledged the trans- 
mitting TNC will generate a poll packet to see if the 
destination TNC is still around. If the poll packet is 
acknowledged then the transmitting TNC will once again 
attempt to send the information packet. Note that if there 
is a periodic noise at the receive TNC that the poll packets 
might be received but that a particularly long information 
packet might never get through. In that case the retry 
process might take place until manual intervention oc- 
curs. (See Retry) 


Port 

TNCs are two port devices, RS-232 and radio. With net- 
work software, like ROSE or TheNET, they can com- 
municate with other network nodes via either port. If 
a stack of TNCs is networked using a diode matrix then 
what is referred to as the ports are usually the radio port 
of each TNC. Thus a 3 radio node is referred to asa 3 
port node. 


PROM 
Programmable Read Only Memory. (See EPROM) 


Protected Backbone 

A protected backbone is a backbone where none of the 
known devices involved in the backbone will accept traffic 
from any unknown device. (See Backbone) 


Protocol 


A scheme for communications. There are many differ- 
ent protocols for many different purposes. AX.25 is a 
protocol which describes how small computers will talk 
to each other. TCP/IP is a protocol which describes how 
computers of all sizes will talk to each other, using more 
computers as mid stations. TheNET protocol describes 
how nodes in a network will talk to one another. 


Quality 

TheNET software allows for a factor called quality. The 
quality factor is used to determine the path length for 
a network connect. 

Quality factors are determined as part of the node 
broadcast sequence. Each node sends a one way message 
out every half hour (setable) that tells it’s neighbors what 
nodes are listed in the nodes table. The neighbors have 
a quality factor that associates incoming node listings 
to new quality values. (See Nodes Broadcasts which is 
part of Theory of Operation in the Resource Manual) 
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RAM 


Random Access Memory. This is an IC in a computer 
that holds data only so long as power is applied. This 
is usually used only for storage during the execution of 
a program. TNCs use RAM for temporary storage, 
messages and parameters. Normally TNC RAMs are 
powered all the time using a lithium battery in the TNC. 


Real Time 

When a signal is sent and a result is expected back within 
a short enough time to fall within a person's attention 
span the operation is said to be in Real Time. Key- 
board to keyboard operation is real time. Keyboard to 
server is real time. Reading your mail from a remote 
BBS is real time. Sending a message to a friend via a 
packet BBS is not real time because the sender doesn't 
know how long it will be before the friend's answer comes 
back. 


Redundancy Path 


In a mature packet network more than one path would 
exist between every two points. If one of the two paths 
is preferred due to load handling capability or number 
of node hops then that path would be called the primary 
path. The other path would be called the redundancy 
path. (See Path) 


Response Time 

This is the time between sending data to a remote de- 
vice before an expected response returns to the originat- 
ing station. 


RETRY 


This is a process by which a packet that is not ac- 
knowledged is regenerated. 


Reverse Forward 


This is a feature of all modern BBSs and some PMSs 
where a connecting BBS may request if any mail is 
available to be taken by the connecting BBS. The prompt 
and answer exchange that takes place is in plain text 
and may be monitored if you are curious. (See Forward.) 


ROSE 

RATS Open System Environment: This is a network- 
ing software package created by Tom Moulton, W2VY, 
in concert with the Radio Amateur Telecommunications 
Society in New Jersey which implements a multiport, 
multistation packet radio network. The software con- 
sists of several parts. The most major part is in the form 
of an EPROM that resides in a TNC2 compatible TNC. 
Other parts include network management and system 
operation tools that run on a PC compatible but which 
are not integral to the network’s day to day operation. 
ROSE operation is done with the use of site callsigns 
and numeric designations that are traditionally in the 
form of a telephone area code and local code. The user 


N.A.P.R.A. Notebook v1.0 
© NAPRA 1992 


treats the local ROSE ‘switch’ as a digipeater with the 
destination switch’s numeric code as a second digipeater 
in the user connect sequence. 


Example: 
¢ To connect from WB2DWD’s station in Long 
Valley NJ to KA2DEW’s station in Potsdam NY 
a user would do: 
C KA2DEW v NX2P-3,315268 
where KA2DEW is the destination user's call- 
sign, NX2P-3 is the user’s local switch, and 315268 
is the designation for the switch in KA2DEW’s 
area and on the frequency that KA2ZDEW will be 
operating. Note that KA2DEW will get a connect 
message that looks like: 
*** Connected to WB2DWD via K2CC-3,201876 
where WB2DWD is the originating station, 
K2CC-3 is KA2DEW’s local switch and 201876 
is the numeric designation for WB2DWD’s local 
switch. 201876 is the same switch as NX2P-3 
and 315268 is the same switch as K2CC-3 
The linking methodology between ROSE switches is very 
open to the design requirements of the implementation. 
ROSE switches may be linked with a common trunk 
frequency, with hidden transmitter free backbones, or 
on the user access frequencies. ROSE switches may be 
built with from one to many TNCs on many frequen- 
cies. 
The routing methodology used in ROSE is based on a 
fixed table stored in RAM in each switch and downloaded 
by the designated sysop. This may be done locally or 
from the far end of the network. The routing may list 
individual switches and include the neighbor for each 
individual switch or the switches may be listed by class 
allowing whole ‘area codes’ to be listed with the same 
neighbor node. Alternate routes may also be specified. 
Ifa link fails completely or is taken off the air the system 
would adapt quickly. 
This software has been in Beta test station for several 
years and as of August of 90 has been used successfully 
for building multiport nodes. 
A notable difference between ROSE and TheNET is that 
- with ROSE a user doesn’t have to know about any in- 
tervening hardware between his entry and exit ports in 
the network. On the other hand the user is also unable 
to find out anything about the intervening hardware. 


Route Stepping 

One of the features of TheNET is that an individual may 
hunt through a TheNET networking and take advan- 
tage of local Routes commands to determine what all 
of the neighbors of a particular node are. With this 
knowledge the user may then connect to a neighbor node 
and repeat the process. In this way an individual user 
may entirely map the existing network or collection of 
networks. This has been taken as a disadvantage by 
some network developers due to the (apparently) vast 
amount of network traffic that is generated by this user- 
play process. 

One advantage of route stepping is that if there is a site 
that is accessible from one end of a network but that is 
not known on the other side of the TheNET network the 
user may simply connect from his/her origin user port 
to a node that knows of the desired site and then con- 
nect to that desired site. This may be done repetitively 
to get to a very distant node. 

Another advantage of route stepping is that there are 
timers internal to the TheNET node that specify how 
long a packet may take to get from one end of the net- 
work to the other. If the packet takes longer than 
specified by the timers then network-end-to-end retries 
are performed. This results in unnecessary network load. 
Furthermore if the retries ever fail then the user is 
disconnected. By making smaller steps the user may 
create a more robust path. (See TheNET) 


Routing Loop 

This is a condition where a packet is sent through a node 
more than once due to routing errors. Routing errors 
can occur when a node is goes off the air or if a backbone 
link is lost. Here is an example of a routing loop. 


LEE E29 GEORGE 

#BBSLK 
#GRGEA KEES Peas 
#SPCNW 


If #SPCNW tells the #GRGEA about SPCNDL node and 
then the 440 backbone goes down #GRGEA will still tell 
GEORGE and #BBSLK about SPCNDL. In it's next 
broadcast GEORGE will tell #BBSLK about SPCNDL. 
#GRGWE will then tell #GRGEA about SPCNDL. Af- 
ter three node broadcasts #GRGEA will forget about the 
440 backbone to #SPCNW but will still know about 
SPCNDL because #BBSLK will have sourced it. 

Now, if a packet comes into #GRGEA destined for 
SPCNDL it will pass it to #BBSLK who will then pass 
it to GEORGE who will then pass it to #GRGEA and 
the loop will continue until time to live runs out. 
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RS-232 

RS-232-C is the Electronics Industry Association (EIA) 
standard number for the most common interface used 
between computers. This is usually called RS-232. A 
signal which uses the RS-232 standard is often said to 
be at RS-232. The computer to TNC connection is at 
RS-232. Normal computer internal data signals use 
ground and +5 volts to indicate a zero or aone. RS-232 
generates -12 volts and +12 volts to indicate a Mark or 
a Space which are analogs to zero and one. A RS-232 
receiver detects a Space as anything greater than +3 and 
a Mark as anything less than +3. (Note: Your editor 
cannot verify this information at this time. Please cor- 
rect me if you can) The reason that this method is used 
for computer to computer signalling is that TTL (Ov -> 
+5v) is more subject to line noise, capacitance and non- 
true grounds than is RS-232. 


Serial Port & Serial Communications 


The part of a computer responsible for sending binary 
data in a serial fashion. Normally computers talk in- 
ternally with parallel data signals, that is that all of the 
important bits for a block of information are sent at once. 
A serial communications uses only one wire which is 
toggled many times for a single block of information. 
Thus a letter A might be sent in parallel all at once when 
it must be sent as a string of ones and zeros in sequence 
in serial. The serial port usually consists of a single chip 
called a UART, a RS-232 driver chip and a connector. 


Server 

A server is any stations that is operating as a service 
to other users than the owner. This may included BBSs, 
DxClusters, DOSgates, TheNET nodes, ROSE nodes, 
TCP/IP hosts etc. 


Site Hardening 

Term for ruggedizing a site by adding backup power, 
shielding or lightning protection. This includes weather 
protection and protection against RF problems or nuclear 
attack. 


Site Manager 
This is the person or persons that are responsible for 
node hardware and site access. 


Site Sponsor 
This is the person or persons who are financially involved 
in acquiring and maintaining node hardware. 


Site Sysop 
This is the person or persons who have software con- 
trol over a node site. 
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SMTP 


Simple Mail Transfer Protocol. This is the part of the 
TCP/IP system which is responsible for sending mail 
between TCP/IP hosts. This is a non real time service 
which operates in a way very similar to normal packet 
BBSs. Mail is generated by a user at a TCP host, with 
a destination address. The host makes the decision of 
what other TCP host the mail should be routed to in order 
to get to the specified destination. Eventually, in zero 
or more hops the mail gets to the destination host. 


SSID 

Secondary Station IDentification. A callsign is normally 
used as an address. In a case where a ham needs to have 
more than one address on the air at the same time the 
callsign may be used with an ssid. There are 16 differ- 
ent possible SSIDs. NK1M-2 is an example of an ad- 
dress using a callsign and an ssid of 2. NK1M is the 
same as NK1M-0. -15 is the highest ssid that can be 
used. 

A function of TheNET, G8BPQ, MSYS and other node 
software is to change the ssid of a callsign that passes 
through the node or network of nodes. If a station con- 
nects to a node with an ssid of 0, when the station con- 
nects out of the node with an ssid of 15. The formula 
used is 15 - ssid = exit ssid. Thus a station using an 
ssid of 4 will emerge from the node or network of nodes 
with an ssid of -11. 


Stream 

AX.25 allows many connections to be made from one 
station at the same time. Each connection is called a 
stream. The origin and address callsign pair for the 
connections must be different for each stream. That is: 
If Iam KA2EIA and I connect to three other stations, I 
can connect to NK1M, K1MEA and NQI1C but I cannot 
connect to NQ1C, NQ1C and K1MEA. This process is 
called multistreaming and is available on most modern 
TNCs. Look at the USERS command in your TNC’s 
manual. 


TCP/IP 

Transmission Control Protocol/Internet Protocol. This 
is a suite of protocols that define the operation over the 
‘Internet’. This package of protocols was used by Phil 
Karn, KA9Q, for the creation of a packet radio version 
of TCP/IP. As this is a fairly mature networking sys- 
tem it supports many features not available in the current 
‘made for ham radio’ protocols. It also has features that 
would take much better advantage of networking re- 
sources for the transmission of volume data than do 
TheNET and ROSE. One problem that TCP/IP for ham 
radio currently has, however, is that it requires a more 
sophisticated computer and a more sophisticated operator 
than are required to operate ROSE and TheNET. (See 
Internet) 


N.A.P.R.A. Notebook v1.0 
© NAPRA 1992 


Terminal 


A terminal is a display entry device. A CRT Terminal, 
which means Cathode Ray Tube terminal is normally 
just called a terminal. They are also referred to as dumb 
terminals. Sometimes a computer is used as a termi- 
nal. 

A terminal is usually a display screen and keyboard 
hooked to an RS-232 port. When you type on the key- 
board data is sent out of the TxData pin of the RS-232 
connector on the terminal. When RxData signals are 
detected on the RS-232 connector the text is displayed 
on the screen. 


Time To Live 

When a packet is sent from one TheNET node to another 
TheNET node the packet contains several bytes of in- 
formation which are useful for the intervening TheNET 
nodes. One of those bytes of information is the time- 
to-live. Each time a node relays the packet one hop 
further the time-to-live is decremented. When it dec- 
rements to zero the message is discarded. Thus if the 
number of hops that the packet has to go to reach it's 
specified destination is greater than the initial time-to- 
live the packet won't get there. In addition if the time- 
to-live on the return trip is not high enough an ac- 
knowledgment will not be returned. 


TheNET 

This is a networking software package created by Hans 
Giese, DF2AU, in concert with NORD><LINK in Ger- 
many which implements a multiport, multistation packet 
radio network. The software consists of several parts. 
The most major part is in the form of an EPROM that 
resides in a TNC2 compatible TNC. Other parts include 
node configuration tools that run on a PC compatible 
but which are not required after initial system setup. 
TheNET operation is done with the use of site callsigns 
and mnemonic designations that are traditionally in the 
form of a city name. The user treats the local TheNET 
node as a remote command processor by first connect- 
ing to it, then away from it. 


Example: 


¢ To connect from WB2DWD’s station in Long 
Valley NJ to N2MGTIss station in Potsdam NY a 
user would do: 
C SUSSEX, then when connected, 
C POTSDM, then when connected, 
C N2MGI where N2MGI is the destination user’s 
callsign, SUSSEX is the user’s local switch, and 
POTSDM is the designation for the switch in 
KA2DEW’s area and on the frequency that 
KA2DEW will be operating. This would only work 
if POTSDM showed at SUSSEX’s nodes list. In 
practice with TheNET each connect step can only 
be a few node steps. 


Note that N2MGI will get a connect message that 

looks like: 

*** Connected to WB2DWD-15 

where WB2DWD.-0 is the originating station 

The linking methodology between TheNET nodes is very 
open to the design requirements of the implementation. 
TheNET switches may be linked with a common trunk 
frequency, with hidden transmitter free backbones, or 
on the user access frequencies. TheNET switches may 
be built with from one to many TNCs on many frequen- 
cies. 
The routing methodology used in TheNET is based on 
a dynamic table stored in RAM in each switch and au- 
tomatically generated by periodic information transfers 
between nodes and within restrictions placed on each 
TNC by the designated sysop. This may be done locally 
or from the far end of the network. The routing lists 
individual nodes and includes the neighbor for each in- 
dividual node. Alternate routes are automatically gen- 
erated but in practice are not used. Ifa link fails com- 
pletely or is taken off the air the system will adapt to 
the lack of that link after a number of hours. 
TheNET has been in use now for several years in the 
US. Recently NJ7P, Bill Beech in Arizona has been 
releasing heavily modified versions of TheNET under 
the name of TheNET Plus. 
A notable difference between TheNET and ROSE is that 
with TheNET a user can delve into the routing tables 
of each of the nodes and find out how the network is put 
together. The user can also determine from available 
information at each node TNC how well the node is 
managed and how well it is integrated into the sur- 
rounding network equipment. On the other hand the 
user is required to know at least some information about 
the network’s architecture, at the minimum, and in some 
areas the user needs to have a very complete knowledge 
of the architecture in order to use the TheNET nodes 
effectively. 
(See ssid.) 


TheNET PARMS 

TheNET nodes, which run in TNCs, operate using timers 
and other parameters that are initialized in the EPROM 
when it is burned. Some of these timers and param- 
eters may be modified over the air by the site sysop. A 
complete description of these parms was published in 
the NAPRA Notebook. (See TheNET) 


Three Way Wireline Link 

This is a circuit that allows up to 3 TNCs to be 
connected together as if they were over the air to each 
other. This circuit bypasses the modems in each TNC 
so that the three TNCs may communicate at high 
speed. The three way wireline link circuit was 
presented in the NEDA Quarterly volume 1, number 
4 and is also presented in the current NAPRA No¢te- 
book. (See wireline link) 
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Throughput 

This term specifies how many bytes sent by an origin 
station actually reach the destination station in a give 
period of time. Throughput is a much better number 
to describe network performance than baud rate. Baud 
rate only describes the number of bit transitions that 
may possibly leave a transmitter in a second. Throughput 
is a statistic that actually means something to an end 
user. Throughput is calculated either by observation or 
by taking the original baud rate, given in bytes per second, 
subtracting out all of the wasted time and overhead due 
to network protocols, the lost time due to choking and 
due to collisions. (See Choke) 


TINK 
Slang for TNC. 


TNC 


Terminal Node Controller. This is the brains that con- 
nects the user’s terminal to his radio so that he can 
communicate to other stations. The TNC’s job is to take 
text typed on the terminal or computer and store it un- 
til the user hits a return. At that time the text is sent 
to the destination station. Each line of text (ended with 
a carriage return) becomes a packet and is stored in the 
TNC until it can be sent to the destination station. 
The TNC also has commands that let the user set the 
callsign of the station and set up communications with 
another station or stations (Connect command). 

The TNC is like a home phone modem in that it con- 
verts digital character data to tones. The big difference 
between a TNC and a phone modem is that the TNC 
has the intelligence to direct your traffic to a specific 
destination and to receive connects using it’s own mi- 
croprocessor and internal software. A phone modem is 
relatively stupid in that it can only work on a channel 
where there is only one destination, i.e. a telephone. 
By changing the internal software TNCs may also be 
used for other purposes besides home station use. This 
includes running as part of a set of TNCs in a network 
node. 


TTL 


Transistor Transistor Logic. This is the name for logic 
circuits which operate using OV for a zero and 5V fora 
one to do binary operations. 


UART 


Universal Asynchronous Receiver/Transmitter. This is 
an IC which is used in a computer to construct a serial 
port. 
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Unproto 


An unproto packet is a packet transmitted without ex- 
pecting a response. Technically it is called a UI frame 
which means Unnumbered Information frame (frame 
= packet). If a packet station were to send a beacon for 
all to see or were to call CQ, the station would use a Un- 
proto packet. 


User Channel 

The frequency designated for users to access the net- 
work. This frequency would be devoid of servers and 
other nodes aside from the one designated. (See LAN, | 
WAN) 


WAN 

Wide Area Network: This is a system where many serv- 
ers and nodes may talk to each other. This kind of system 
is rugged in that communications would probably not 
be compromised if a single site went off the air. The major 
problem with this methodology is that if the only packet 
systems available are of this type then users, which 
present transient loading, will find that the WAN is 
unable to support massive intermittent loads during peak 
usage times. This causes frustration and leads to non- 
utilization of packet. (See LAN) 

Wireline Link 

This is a connection between the modem headers of a 
pair or more of TNCs such that the TNCs communicate 
via their radio ports but without an intervening pair of 
radios. Because the modems are bypassed the TNCs 
may talk at a higher data rate than 1200. This circuit 
is described under Burning the EPROMs and Putting 
It All Together, part of the Resource Manual in this Note- 
book. (See Three way wireline link) 


Wink ‘N Blink Mod 

This is a modification to a TNC2 that allows that the 
CON and STA lights are used to monitor the RS-232 
port’s DCD and CTS signals. These signals act as 
PTT and Carrier Detect on the RS-232 so making this 
mod allows an observer to watch activity between the 
several TNCs at a single node site. This is an excel- 
lent diagnostic tool and is fun to watch. This circuit 
was described in the Fall NEDA Quarterly of 1990, 
volume 1, number 4 and is also described under 
Burning the EPROMs and Putting It All Together, 
part of the TheNET Plus Resource Manual. 
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North East Digital Association Quarterly 
Compendium of past issues 


NEDA is a club which has similar goals to NAPRA. The majority of NEDA's members are in Ontario, Quebec, 
New England and New York. NEDA has a history which is quite a bit different than NAPRA but it’s goals and 
methods are similar. Since January of 1990 NEDA has been publishing technical articles in it's Quarterly. Many 
of those articles are of high value to packet network builders and users. Since NEDA gives permission for any 
non profit group to copy them we have done so. 


The following pages have all of the technical articles printed in past NEDA Quarterlies that are not specifi- 
cally outdated. Some of the information is redundant with what is published earlier in this Notebook. They are 
still included so as to show differing points of view. Some also deliver the information in different ways. This 
may help with explanations for topics which are not altogether clear. 


Also included are graphical articles for packet node sites that have been in past NEDA Quarterlies. Although 
the sites involved may have changed and the information is no longer current they still stand as decent examples 
of network construction. 


Disclaimer: The articles presented in this section are from the point of view of the author. They do not necessarily 
reflect NAPRA policy. Please keep an open mind. If you would like to get the Quarterly yourself you should send 
a letter to NEDA, Box 563 Manchester NH 03105. 
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Death By Competition 


Before reading the rest of this 
editorial comment I would like 
readers to re-read the above state- 
ment, and forgetting about ourselves 
as amateurs consider how our 
country would have developed if not 
for the framework of our government 
which was forged by men like Tho- 
mas Jefferson. 


It is no wonder that our country 
developed as fast as it did for infor- 
mation on what we had, how good it 
was and what made things tick was 
readily available to anyone who cared 
to know. Furthermore anyone who 
wanted to be a part of it all had only 
to express sufficient interest, intellect 
and time for involvement to be im- 
mediately planted firmly in some 
aspect of the grand scheme of things. 
No aspect was truly closed to those 
desiring involvement. Politics, so- 
ciety, industry, administration, ag- 
riculture, exploration and dozens of 
other areas were attractions for 
anyone with such leanings. 


I would like everyone to consider 
that Amateur Radio is just as open 
and just as ripe for development and 
involvement as the example above. 
The problem is that without this 
understanding and an exchange of 
free information it cannot continue 
to attract involvement by those who 
are best capable of helping us grow. 
If this happens we will stagnate and 
wither in our knowledge base thus 
creating our own demise. 


So what is the bottom line here? 
Involvement 
Information 
Cooperation 


It is hard to believe that anyone 
reading this who is a NEDA mem- 
ber is not already involved in packet 
to the point that they can actively 
promote our cause. And What you 
ask is our cause? Very simply it is 
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to implement, promote and widely 
share those technical advances in 
networking and implementation 
philosophy that ultimately improve 
interconnectability of all packet 
services. Not just users. Not just 
Bulletin Boards. Not just special 
services like a DOSgate or DxCluster 
or CROWD port and certainly not 
just any one network containing such 
things within it! All packet services 
- inclusive - in its entirety - every- 
where - globally. We must openly 
encourage the wholesome discretion 
referred to by Mr. Jefferson but also 
make sure it is an ‘informed’ dis- 
cretion. There is much 'power' to 
implement our technology with 
mostly just the use of the correct 
information, but there is no better 
way to efficiently use technical re- 
sources and hardware than to uni- 
versally share whatever is available 
for all applications. This does require 
up front planning when doing things 
however as retrofits and add-ons 
rarely (if ever) achieve such efficiency. 


Death by competition 

The real killer of efficiency is non 
compatible independent implemen- 
tation of redundant applications. 
Yes, we see them all the time in the 
private sector because in the com- 
mercial world most communications 
users are in competition with each 
other. They wish to have indepen- 
dent paths of communications that 
each individual group controls totally 
to their own financial (or image) gain. 
Certainly this is all right if such in- 
dividuals can afford it all and it 
doesn't detract from the capacity of 
another group to reproduce their own 
services, but increasingly this is 
proving not be the case. 


A very recognizable example of 
this effect in the non-ham world re- 
cently has been brought to light by 
the needs of state governments in 
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their statewide communications net- 
works. The problem was that the 
lack of coordinated government and 
public safety communications ser- 
vices caused enormous drain on 
statewide budgets. The statewide law 
enforcement agencies had a state- 
wide network; the departments of 
education, transportation, health, 
social services, fire services, civil 
defense, administration, etc. ad 
nauseam each had their own state- 
wide communications network! The 
cost and maintenance of each system 
was variable because they were all 
just slightly different, but the over- 
all cost of both implementation and 
operation was enormous not to 
mention the fact that these systems 
rarely had capacity to cross com- 
municate! Budget administrators, 
upon uncovering this “turf protect- 
ing” policy creating essentially pri- 
vate (to each agency) networks for 
each agency, rioted at the misuse and 
inefficient application of taxpayer's 
bucks. 


Centralized Telecommunications 
Agencies with the directive to create 
a single statewide network with more 
than enough capacity to handle all 
government agency needs were 
quickly created by state governments 
capable of fast response and dire need 
for financial recovery. Previous in- 
dependent networks were rapidly 
phased out and integrated network 
use mandated. Systems created with 
long term objectives of integrating 
services quickly proved to be effective 
and drastically reduced the expenses 
involved with keeping themselves 
going. Public service agencies dis- 
covered the real value of 
“interoperability”. Indeed, several 
state systems paid for themselves in 
record time! 
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How was this done? Cooperation 
and joint involvement was the key. 
It is interesting to note that in many 
states where such cooperative efforts 
were not mandated by some high 
level authority the wallowing in fi- 
nancial mire and inefficiency still 
goes on. This sure says something 
for cooperation in government eh? 


There are really not many of dif- 
ferences in amateur packet net- 
working and government communi- 


cations services networking. We both 
work on limited funds, resources, 
manpower, support, time and a few 
other things as well (recognition and 
respect for personal sacrifice for 
others in the performance of public 
services for example?) 


There are now in existence some 
real good examples of large scale 
amateur cooperative efforts that have 
achieved significant, even historical, 
events. Some of them have really 


opened the eyes of government and 
commercial observers who then copy 
our examples. New mode develop- 
ments, super inexpensive commu- 
nications satellites in orbit serving 
globally and now wide scale data 
networking on a flea power budget. 
Lets get on with things as innovators, 
supporters and educators of our fel- 
low amateurs. But most of all, lets 
do it together! 


—Dana Jonas, WA2WNI 
Copied from NEDA Quarterly aug 90 


‘Speedup for Relay Keyed Radios 


Copied from NEDA Quarterly jun 90 
Here’s a simple trick to improve 
those radios of yours with relay 
keying. While modifying for PIN 
diode switching would be great, some 
radios switch so many different 
voltages that it’s not feasible to go to 
solid state switching. I tested sev- 
eral relays and found that while most 
will turn on in under 10 msec, the 
time drop out time was at least 3 
times that long. When the relay is 
turned off, current continues to flow 
through it via the snubber diode. The 
current dies out exponentially de- 
pending upon the relay coil’s resis- 
tance and inductance, but in the 
meantime it keeps the relay ener- 


gized. By adding resistance in series 
with the snubber diode you can de- 
crease that time constant and speed 
things up. Adding this resistance will 
increase the voltage transient that 
the keying transistor will see, so you 
must be careful not to use too big of 
a resistor. The procedure to follow 
is this: 

>Look up the Collector - Emitter 
voltage rating of the keying transistor 
hooked to the relay. 


>Divide the voltage rating by the 
voltage applied to the relay and write 
down that ratio. 


>Measure the resistance of the 
relay (measure it both directions and 


use the higher reading so that you 
aren’t just reading the diode across 
it.) 

>Multiply the resistance you 
measured by the ratio calculated 
above, and round that number down 
to the nearest available resistor 
value. 


>Add this resistor in series with 
the snubber diode that is across the 
relay. 


When you are done, the voltage 
transient that occurs at the collector 
of the transistor when it unkeys will 
be just under the voltage rating of the 
transistor. The time for the relay to 
unkey will be reduced by a factor 
equal to the ratio calculated above. 


—Rich Place, WB2JLR 


Copied from NEDA Quarterly apr 90 
Here in the Rochester area there 
is a fair amount of weak signal VHF 
activity. One problems is that no one 
knows when the bands are going to 
open, hence they'll probably miss 
some much needed grids unless 
monitoring all the time. In the 
Rochester VHF group there used to 
be a system where stations gave one 
another a “one ringer” on the phone 
as aband opening alert. There is now 
a simplex 2 meter frequency used for 
this purpose, however many stations 
are outside the 2 meter simplex 
range. This sounds to me like a 
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VHF Cluster Proposal 
perfect application of packet radio. 
What is needed is a VHFC Luster 
similar to the DxCluster systems now 
in use for HF DXing. Since no such 
VHFCLuster system exists yet, I 
propose that one channel on one or 
more CROWD ports be designated as 
a weak signal VHF spotting channel. 
Aurora or E skip openings would no 
longer be missed due to beam head- 
ing or lack of monitoring. The 
CROWD would also make an easy 
way to set up microwave schedules 
with other stations and stations could 
also advertise what grids they are 
looking for on which bands etc. If we 
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try and use too many different 
CROWDs to start with, there may 
not be enough stations on any one 
CROWD to make it useful. To get 
things rolling Id like to suggest that 
we use channel 144 of the CROWD 
at BERK and the one at CANDGA. 
Please think about this idea and send 
me your comments or bring them to 
the July meeting. Maybe we can 
come up with some more formal de- 
cision of whether to adopt such a 
plan. Should we set aside any other 
CROWD channels for special pur- 
poses (like Emergency traffic for 
example) ? 


—Rich Place, WB2JLR 
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Wireline Linking of 3 TAPR2 TNCs at 9600 baud 


Copied from NEDA Quarterly nov 90 The modem header has __ “dem Disconnect Header 

TNCs are two port devices. For these signals on it but tb ae 
TheNET we tie the serial ports of there are some problems. output Combiners 
several TNCs together to form a The Tx data from the SIO bar sow 
multiport node. For TheNET this js normally gated in the coy bi 
works. But what if you want to tie modem and/or by the radio 


a different kind of device into your 
TheNET node, like a DOSgate or 
personal TNC station running nor- 
mal TNC1.1.7 software or personal 
mailbox software? Or, what if you 
want to tie more than 5 TheNET 
nodes together? The RS-232 drivers 
won't like this. 


Here is a solution. What I've done 
is connected the modem headers of 
three TNCs together. This allows the 
TNCs to talk, as if over the radio, to 
each other. Because the TNCs talk 
using AX.25 level 2 they can all talk 
to each other, even if one is running 
TheNET, one KISS and one a nor- 
mal AX.25 user station. Another 
popular use for this is to tie a pair 
of TheNET clusters together at the 
same site while leaving a debugging 
station, home station or BBS tied in 
all the time. If you already intend 
to tie the two TheNET clusters to- 
gether you can add a user station for 
the cost of just the user TNC anda 
couple of TTL chips. 


Each TNC2 has a modem discon- 
nect header. This header is hooked 
in between the Z80 SIO (serial in- 
terface chip) and the modem/PTT/ 
DCD circuits. All signals at the 
disconnect header are at TTL (Ov/5v) 
levels. This means that we can play 
with these levels using regular cheep 
logic chips. Another thing this means 
is that the data travelling along the 
wires will be susceptible to noise so 
keep the wires less than a couple of 
feet long. Just long enough so that 
the TNCs can be taken apart will 
work fine. 


Because we are bypassing the 
modem circuits we can set the radio 
port baud rate up as high as it will 
go. Tiny 2s run at 19.2Kbaud. 


The circuit: 

Each TNC had 4 lines which come 
out of each TNC box. The lines are 
Tx Data, Rx Data, PTT and COR. 
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that is transmitting the 
data. Because we're hook- 
ing the Tx data line directly 
to the other TNCs without Fin” 
pu 
going through a radio we 
have to gate this data our- 
selves. If you look at the Tx 
data signal on the modem 
disconnect header (pin 19) 
you'll see that it's putting out 
a square wave all the time the 
TNC is on. When the TNC 


Pin 19 
TxData output 


goes to transmit the RTS out- PTT tom tnca 
put line (pin 5 of the disc header) ptt tom tNcB 


goes low. So I have inverted the 
disc header RTS signal, then we 
use this signal to gate the Tx data 
signal. This process inverts it so 
we use the 3rd part of the 74LS00 to 
invert it back. Next the Tx data 
signal is ORed with the Tx data from 
another TNC and the output of that 
goes to the 3rd TNC. The Tx data 
from each TNC goes to 2 OR gates, 
one for each of the other two TNCs. 
Your combiner circuit will use 3 OR 
gates (74LS32) and 3 NAND gates 
(74LS00). The circuit in each TNC 
takes 3 or 4 NAND gates. Because 
there are 4 gates in each package you 
will need a total of 5 packages to 
make the 3 TNC coupler. I mounted 
the perf board which held the 2 
coupler chips in the case with one of 
the TNCs. I mounted each of the 
TXGATE circuits in the TNC which 
it served. 


The DCD circuits for the Tiny 2 
and the MFJ1270 are different;. 
You'll need an inverter in line with 
the DCD signal for the Tiny 2 (shown 
in the diagram). The reason that we 
run the DCD signal into pin 5 of the 
DIN radio connector is that this way 
we get to see the DCD LED work. 


The light show is fabulous when 
this thing is working. For further 
light show with the Tiny 2 running 
TheNET try this modification: 


TNCA 
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TxData from 


TxData from 
TNCB 


RxData 
from 
xdata 
combiner 
output) 
tran "WShcccadacbn 
; COR signal 
Pepbenh (rom P 
Pin 5on 5 havent! a combiner) 
pin DIN 
connector 


Use Inverter (NAND gate) for TAPR2 versions (MF J). 
Use short for PacCom Tiny 2. 


74.800 
RxData to TNC C 


Wink and Blink Mod 

Lift pins 16 and 25 on the SIO. 
(You'll have to pull the chip out of the 
socket, bend the pins out straight and 
plug it back in). Now, on the bottom 
of the PC board, put a jumper be- 
tween pin 16 of the SIO socket and 
23 of the SIO socket and another 
between pin 25 of the SIO socket and 
pin 24 of the SIO socket. Do these 
jumpers on the bottom of the board. 


What this does is make the STA 
light indicate RS-232 Receive activ- 
ity and the CON light indicate RS- 
232 Transmit. If you are using the 
3 way wireline to tie two or three 
TheNET clusters together and if you 
do the STA/CON modification to each 
TheNET TNC in the 3 way then 
you'll have a decent diagnostic tool 
to show you all of the activity on any 
of your TheNET ports. 


Another trick 

If you are coupling two TheNET 
clusters together and using the third 
TNC asa user station you can set the 
third TNC into TRACE mode ON 
and watch the TheNETese between 
the two clusters. 


—Tadd Torborg, KA2DEW 


COR to TNC C 
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Two TNCs on One Radio 


Copied from NEDA Quarterly June 92 
4-30-92 Rich Place WB2JLR 


Here is a simple circuit that will let you interface your 
own personal packet station to the node in your home. 
I use it for interfacing my packet station, WB2JLR and 
WB2JLR-4 (PMS) to the CANDGA node. It lets me moni- 
tor 144.99, the user port frequency, without requiring 
a second radio. I can also connect directly to anyone on 
144.99, as well as connecting to the node. 

How it works 

The circuit uses a quad op-amp, which could be any 
garden variety part such as an LM324 or TL084. Three 
sections of the op-amp are used a summing circuits to 


Audio from TNC #1 R2 10K 


R3 
Audio from TNC #2 ae = 
+6V0O 1/4 LM324 


R4 


RS 10K 


Receive Audio 3 
+6VO 


R9 


PTT from TNC #1 


a 


PTT from TNC #2 SW1 SPST 
Keying Switch 


PTT to radio 3 


12 Volt 
11 SS ier ADIN A-OF IG 


Ground = 59 PIN1 OF IC 
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10K 
ear Rx Audio to TNC#1 


R7 10K rae Rx Audio to TNC#2 
R8 10K 5 
+6VO 3/4 LM324 
LM324 


R10 10K 


R11 10K 


combine two audio sources into one. TNC#1 is the user 
port for the node, and TNC#2 is another TNC for your 
personal use and possibly PMS mailbox. The transmit 
audio from each of the TNCs is summed by the first sec- 
tion of the op-amp to provide a combined audio signal 
to the 2 meter radio. In this way either TNC can transmit 
out on the user port frequency. The second op-amp section 
combines the receiver audio with the transmit audio from 
TNC#2, and feeds it to TNC#1. This allows TNC#1 (the 
user port) to hear both the 2 meter signal and the sig- 
nal from your own TNC. The third op-amp section com- 
bines the receiver audio with the transmit audio from 
TNC#1, and feeds it to TNC#2. This makes it so that 
TNC#2 (your station) can hear both signals coming in 
on 2 meters, and the 
signals from the node. 


C1 10uF 
i. An added feature is 
poo the ability to control 
To Transmitter the key line. Nor- 
mally a switch con- 
nects the PTT line from 
the two TNCs in parallel 
so that either of them can 
key the radio. It is pos- 
sible to open the switch so 
that transmitted signals 
from the personal station 
to the node do not key the 
2 meter radio and go out 
over the air. This may be 
desired to provide privacy 
when sysoping the node. 


Notes: 


Each circuit has unity 
gain in all directions. The 
feedback resistors on the 
op-amps could be made 
variable if gain adjust- 
ment was desired. 


10K 


2/4 LM324 


10K 


It may be necessary to 
add series capacitors in all 
of the input and output 
lines, depending upon the 
TNC and radio. If the 
units are already AC 
coupled then no addi- 
tional caps are needed. 


[Another qpproach lmere costly) to get 
ting the node owner a conmect into the ner 
work for his own TIVE /s shown in the 
The!VE7 Kesource (anual under the chqp- 
ter Burning EP ROMs and Fitting /t Al 
Together.-ed] 

—Rich Place, WB2JLR 
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Copied from NEDA Quarterly feb 91 

Are you having trouble with more 
retries than you should when the 
frequency is busy? Or maybe one 
station is hogging it all and you can’t 
figure out why there is no room for 
your packets. Here are some ideas 
that may help the situation. Get 
together with your fellow packeteers 
that are operating on the local user 
port and review the settings of the 
timers in your TNC’s. Much of the 
following information was contained 
in a couple of articles by WB6RQN 
in 73 magazine some time ago, and 
we have found the suggestions to be 
very helpful on the VNH user port. 
It does require a cooperative effort 
of all the users. 


TXDelay 

Run it as low as you can and still 
work the stations you normally 
converse with. I can run my 
TXDelay at 8 quite reliably when 
working VNH. VNH has a very fast 
receiver, however a setting of 20 to 
30 is required to accommodate some 
of the local stations (I'm working on 
them, hi) that connect to me in the 
occasions that they can work me 
direct and not through VNH. 


Note: True DCD in the TNC will 
drastically improve your receive re- 


sponse time. True DCD boards are 
available from PacComm for about 
$26.00 and these will work with most 
TNC’s that have the 3105 modem 
chip. It’s very easy to install, you just 
pull out the 3105, plug in the board, 
then plug the 3105 back into the new 
board. Open up your squelch, and 
away you go. The MFJ TNC’s are 
represented to have true DCD al- 
ready installed, but I have found it 
does not work effectively with some 
receivers. The only way you can tell 
is to try running your squelch open, 
and see if the DCD light shows on 
receiver noise. If it doesn’t light with 
your audio gain control set properly 
you ve got it made. Running with the 
squelch open makes for a faster re- 
ceive system. 


Non-Persistent CSMA 

If your TNC has ‘non-persistent 
CSMA’ (Carrier-Sensed Multiple 
Access), use the following settings. 
You can determine this by looking at 
your commands list. If you have it, 
the commands PErsist, PPersist and 
SLottime will be in your DISPlay. 


SLottime: Set to equal TXDelay 


PErsist: Set to equal 255 x (1/n) 
where n = the number of stations 
using the channel other than you. 


Pre/de-emphasis 


Copied from NEDA Quarterly feb 91 

Using 1200 baud modems and 
FM radios there is a theoretical 
advantage of not using pre-emphasis 
and deemphasis. Tests run show 
the advantage to be in the neigh- 
borhood of 2 dB. 


Knowing this, and wanting my 
User port to work its very best, I 
made a serious mistake; I disabled 
the pre-emphasis and deemphasis. 
To get the 2 dB advantage you must 
disable the emphasis at both ends 
of the link. Defeating it at one end 
of the link but not the other results 
in delay distortion of the data, which 
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can be disastrous. Depending upon 


the modem chip used, the radios will 
either work marginally, or not at all. 
Since most users connect to their 
TNCs via the microphone and 
speaker jack, they have pre-emphasis 
and deemphasis, so the User port 
radio in the node needs it too. 


On the other hand, if you have a 
long haul backbone link and think 
that another 2dB will make a dif- 
ference, this would be an easy way 
to get it. Just be sure that both ends 
of the link get the changes. 


—Rich Place, WB2JLR 
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Suggested Packet Settings 


PPersist: set to ON 
DWait: Set to 0 


If you do not have non-persistent 
CSMA then DWait is set to twice the 
value of the highest TXDelay setting 
of all the stations in the area. This 
will do a similar job to what non- 
persistent CSMA does. 


FRack 

Set to 5 or greater, 10 works pretty 
well if it’s busy. 
MAXframe 

Set to 1. This gives everybody's 
packet a chance at the frequency, in 
its respective order. Plus it cuts down 
on retries if the frequency is loaded 
with hidden transmitters. I have 
found this one to be a highly con- 
troversial issue. 6 people will give 
you 6 different answers on what is 
best for MAXframe, plus the square 
of that number of reasons why one 
is better than the other. All I can say 
is 1 works best for me. If the fre- 
quency isn’t busy and there are no 
hidden transmitters around hitting 
your packets with big blasts of data 
then higher numbers will work fine. 
—Cal Stiles, W1JFP 


Mount Ascutney Packet Radio 
Association, (MAPRA), The VNH folks. 


N.A.P.R.A. Notebook v1.0 
© NAPRA 1992 
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By the summer of 1988 KA2DEW 
and WA2WNI had been conversing 
regularly via packet for about 2 years. 
KA2DEW lived in a rented house 
with John Painter in Nashua NH. 
WA2WNI lived with his wife and two 
kids in Valatie NY near Albany. The 
path that they used was often digi- 
peating through two very well placed 
digipeaters over the distance of 150 
or so miles. Other times they would 
maneuver their way through the 
221.11 backbone and still at other 
times they would rely on the PBBS 
systems to deliver their mail over- 
night. Both WA2WNI and DEW had 
WORLI PBBSs of their own and both 
ran those PBBSs with a separate 2m 
user channel and 440 or 220 ‘back- 
bone’ channel for forwarding and 
whatnot. 


The reason that the summer of 
1988 is important is that it was 
around that time that the level of 
frustration from the difficulties of 
trafficing mail and from trying real 
time packet from Albany to Nashua 
reached a threshold where the two 
decided to do something about it. 


John Painter is important to this 
story because as he was sharing a 
house with DEW he had observed 
these goings on. John, or Tjp (The 
john painter) as he likes to be called, 
is a technical person. He makes his 
living consulting to various compa- 
nies that need custom VAX/VMS 
software to do tiny little nefarious 
tasks like graphics or dual ported 
diskdrive support etc.. John had 
observed Tadd, KA2ZDEW, on the 
phone with Dana, WA2WNI, for all 
hours of the night trying to find 
packet routes that work. 


Now, Tadd and Dana were avid 
followers of the goings on in the New 
York metro area and had seen the 
application of TheNET in multiport 
nodes under the auspices of the 
Eastnet Backbone Network. Doug, 
WB2KMY (Kiss My Yagi) had taken 
Tadd and Dana under his wing to 
educate them as to technical solu- 
tions using the multiport TheNET 


N.A.P.R.A.. Notebook v1.0 
© NAPRA 1992 


The HexiPus™ Story 


design. Tadd and Dana learned well. 
One thing they learned quickly is 
that building those icky diode matri- 
ces is a pain in the derriere. 


Tjp was in on one of these con- 
struction projects (it was unavoid- 
able) and decided that this was a 
perfect application for his Macintosh 
and McCAD program. Presto chango 
cherrio and the Octopus was born. 
John made 200 of the boards and he 
made them 8 port figuring that if 4 
ports was good, 8 would sell like hot 
cakes. This was all based on Tadd 
and Dana’s prediction that the Oc- 
topus would make node manufacture 
easy enough that people would use 
them. [They were lying. They just 
wanted the boards hi] 


Well.. 2 years later the Octopus 
boards are all sold out. It was time 
to make more. Many things have 
happened in the last 2 years. For one 
thing, NEDA was born out of the 
incredible growth in multiport nodes 
that occurred in the vicinity of Albany 
and Nashua [hmm...]. John has 
moved to Kansas City, Tadd recently 
to Potsdam NY. So.. the NEDA 
board of directors made a general 
statement that a replacement Octo- 
pus was required. 


Rich, WB2JLR, took the project 
and ran with it, creating the 
HexiPus™. The reason that NEDA 
wanted a new board were several 


fold: 


1> 8 ports was deemed electrically 
unsound due to loading problems 
when one TNC is driving 7 others. 
6 ports was deemed more appropri- 
ate. 


2> The Tjp Octopus didn’t say 
anything about NEDA. 


3> The Tjp Octopus was made 
small to keep costs low. The size is 
uncomfortable for some to construct. 


4> John Painter (Tjp) wasn’t 
around when the time came to make 
these boards. He has since been back 
in contact and is planning on work- 
ing on other projects for NEDA. 
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So, NEDA now has 200 HexiPus™ 
boards. They say NEDA all over 
them. The club formed a committee 
headed by WA2TVE, Howie, to mail 
the boards. Orders will be processed 
by WB1DSW, Herb, who is the club 
treasurer and who picks up the mail 
at the POBox. 


The price for the boards with di- 
odes as a kit is $22.95 plus $4 for 
shipping. 

The price for the boards with di- 


odes and 9-pin Dshell connectors is 
$29.95 plus $4 shipping. 


The Dshell connectors are female 
and will require a custom cable to 
plug between the HexiPus™ and a 
Tiny 2. If you are using a MFJ 1270B 
or AEA PK88 (for ROSE) you can get 
a standard PCAT to modem cable 
and modify it to put in the missing 
pin connections. 


The board may be ordered with- 
out connectors if you wish to solder 
directly to the HexiPus™. An al- 
ternative is to put PC mount male 
connectors on the bottom of the 
board. Then you can use standard 
PC monitor extension cables. If you 
find something novel please let 
NEDA know. 


—NEDA 
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Active Coupler for 
Mating A G8BPQ PC to 
a HexiPus™ TheNET/ 
Diode Matrix 


Copied from Quarterly may 91 

Quite a few of the switching sys- 
tems in use today on the NEDA 
network feature not only a multiport 
node but also a PC-based BBS or 
mailbox. The node setup on most of 
these systems involves the use of a 
diode matrix to allow all the TNCs 
to transmit and receive data har- 
moniously with one another. And, 
most of these diode matrices are in 
the form of a small circuit card (like 
NEDA's HexiPus™ ) which holds the 
various passive components. Be- 
cause these sites are often in key 
locations, the SYSOP can, and often 
does, opt to incorporate a BBS or 
mailbox to compliment his/her setup. 


These BBS/mailbox incorporations 
also include in background imple- 
mentations of John Wiseman's out- 
standing network software packet 
(hitherto referred to as "BPQ") to 
allow for multiple connects into and 
out of the mailbox software. BPQ's 
original intent was to provide an easy 
way for hams to create packet data 
switches using their already existing 
IBM or compatible computers. A 
serious drawback exists because 
should the computer crash for 
whatever reason, the switch code 
itself dies until the computer is reset. 
To be effective for a large multiport 
node setup, BPQ often requires a 
very fast (and very expensive) com- 
puter to handle the many streams of 
data. 


A very real advantage of using the 
diode matrix card in conjunction with 
the BBS/mailbox combination is that 
the matrix never "dies" allowing the 
node to stay active even when the 
PC's hardware or operating system 
fails or is taken off the air for what- 
ever reason. 


BPQ code though was thought 
impossible to add direct to this diode 
matrix. The signals just weren't 
compatible. To get around this and 
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IBM PC Serial to HexiPus™ 


PC connector 


Active Adapter 


HexiPus™ connector 


TxDate S—_— ee ee oot) Redeem 
RxData @——H_—_—_———_—___—______ —__—___-_« TxData pin 3 


10KQ 


RTS 


GND 


DCD 


DTR 


CTS pin 8 


GND pin 5 
DTR pin 7 


NEDA node with server connected 


using a wireline link. 


NEDA node with server connected 
using the ‘Active Coupler' 


the more important limitation 
mentioned above, NEDA devised a 
scheme whereby placing two TNCs 
"front-to-front” would allow for the 
node to exist on one side and the 
BBS/Mailbox to exist independently 
on the other. By facing these TNC's 
HDLC (radio) ports toward each 
other, the RS-232 ports became us- 
able - one looking toward the matrix 
and one toward the BPQ code and the 
associated BBS/mailbox. 


As this idea developed, we pro- 
gressed from simply cross wiring the 
Tx/Rx lines off of the DIN connectors 
to picking the digital Tx/Rx signals 
off of the modem disconnect headers 
inside the TNCs. This allowed us to 
set the baud rate of that link up to 
19200 baud. 
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Two advantages were apparent. 
First, the computer could crash all 
it wanted but the node stayed a vi- 
able, active part of the network. 
Second, the computer now was not 
burdened with the awesome task of 
switching data between its serial 
ports plus doing the work on the 
BBS. However, this involved the use 
of two TNCs - a couple of hundred 
bucks just to do this? Boy, was this 
expensive! There must be a better 
way. 

Enter yours truly. I had a spare 
older XT and a temporary allocation 
of TNCs connected to the matrix to 
play with and besides, I had an af- 
ternoon to kill. 
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An Improvement to the Wink-N-Blink Mod 


Copied from NEDA Quarterly feb 91 
In the last Quarterly KA2DEW 
provided a simple TNC conversion 
that modified the STA and CON 
LEDs to show RX and TX data being 
passed over the RS-232 port. This 
was part of his ‘Wireline Linking’ 
article. As you may know a TNC 
running TheNET code does not 
normally use the STA and CON. The 
WNBM (Wink-N-Blink Mod) can be 
very useful as a diagnostic tool to 
show matrix activity such as which 
port is sourcing matrix data and 
when. [See ‘Burning EPROMs and Put- 
ting 1+ All Together” in the TheNET Re- 


source Manual in this document] 


I did find it aesthetically more 
pleasing however to remove the right 
hand 3 LEDs in my Tiny 2s and re- 
arrange them so the LED color order 
from left to right across the front of 
the TNC was Green Red Green Red 
and the power LED became the re- 
maining Yellow. The 1st pair of 
Green/Red show RF port Rx/Tx data 
and the 2nd pair then show the Rx/ 


I reasoned that since BPQ code 
was basically simulating a TNC-like 
device, why couldn't it be directly con- 
nected. I quickly drummed up a 
working version of the BPQ code and 
configured one TNC (with TheNET 
1.16) as a node via the matrix card. 
As a start, I just tied the various lines 
off of a vacant port of the matrix to 
match the RS-232 lines on the PC's 
serial port. Needless to say it didn't 
work. So I started taking things off 
and rearranging them. When I took 
the RX and TX data lines and re- 
versed them, it started working! 
After a brief period of testing, I 
published my findings to NEDA @ 
WINY and got some enthusiastic 
bravos. 


Rich Place, WB2JLR made one 
important addition however which I 
didn't account for. The DCD circuit 
was doomed to fail in that my little 
"experiment’ didn't incorporate more 
than one TNC. Rich was certain that 
placing the PC on the matrix with 
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Tx data appearing on the RS-232 
port. When the TNCs from your node 
are physically stacked on top of one 
another it creates and easy to visu- 
alize pattern so you can quickly fa- 
miliarize yourself with what ncrmal 
data throughput should look like. 
(Not to mention the fantastic light 
show that will entertain visitors to 
your node setup when the node 
matrix is extremely busy!) 


Several useful things cropped up 
almost immediately after I had put 
the WNBM in place. First was that 
I noticed that one port was sending 
many Tx bursts without responses 
from anything. This could not pos- 
sibly be caused by that many ma- 
trix collisions in a row! Indeed it 
wasn't as I quickly found that there 
was an open connection across the 
matrix between two TNCs. The re- 
ceiving TNC wasn't getting the data 
at all so the sending TNC kept trying 
until a the alternate default path took 
it a different way around the matrix. 


more than one TNC would cause 
problems without correctly using the 
DCD/CTS collision detection scheme. 
He drew up a simple way to use the 
DCD circuitry between the PC and 
the matrix using two 2N2222 tran- 
sistors and some pull-up resistors. 
This circuit inverts the states of the 
DCD and CTS lines from the PC, 
making them work with the DCD 
and CTS from the TNC 2s. 


Since implementing this, I have re- 
gained two shiny new TNCs for use 
elsewhere, reduced the load on my 
12V DC power supply by 2 TNCs and 
eliminated a source of traffic delay 
between my BBS and the rest of the 
network. (Someone recently pointed 
out that they had noticed an overall 
improvement in the speediness of the 
return data). As an extra added bo- 
nus, by setting the BPQ code up with 
certain parameters turned on, I get 
to see all the L3 and L4 activity be- 
tween the BBS and it's users as well 
as all internode traffic and TheNET 
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The second item of interest was to 
actually observe 3 TNCs passing data 
that should only have gone through 
2 TNCs. Alas there was a routing 
glitch caused by a locked value. Data 
in one direction was going through 
TNCs A and B while the return data 
was going through TNCs A to C to 
B. Of course one can observe by 
looking at parm and route tables all 
this anyway but it takes a bit of 
looking to see what paths are set up 
to do what. 


One of the observations I am 
keeping an eye on now is the effect 
of circuit choke on the matrix. Ihave 
noted at times the RF ports doing all 
sorts of activity, and the matrix do- 
ing nothing at all. Hopefully if 
somebody gets around to building the 
MoniPus product I'll get a better view 
of all this. The MoniPus is a project 
that has shown up in the NEDA 
minutes recently. 


—Dana Jonas, WA2ZWNI 


activity between the TNCs on the 
matrix, something I was unable to do 
previously. One down side of this 
method is that I lose my "Mail For:" 
beacon (who cares!). 


My thanks go to Rich WB2JLR 
and Mike N1BEE for their help and 
encouragement. Special thanks to 
Tadd KA2DEW and Rob KC3BQ for 
the original thoughts and work on 
getting this system off the ground. 


—Herb Salls, WB1DSW 

[Note: This coupler is not valid for ver- 
sion 406 and later of GEBFQ code. Ver- 
sion 405 and before, using this coupler, will 
not load your TheNVET node's matrix if your 
PC crashes. Version 406 and 406A will 
do so. Beware. When you are configur- 
ing any software, TheWVET or FC based, 
check and see what happens when differ- 
ent parts of your system fail. 

Version 406 of GEBFQ can be hooked to 
the matrix with just a resistor for cou- 


pling. See GEBFPQ's docs. -ed/] 
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Kantronics D4-10 UHF Radio 


Copied from Quarterly nov 91 

These are some notes based on our 
experiences (over the last 10 days) 
of making the new Kantronics D4- 
10 radios work at 19.2 KB. Our 
group is using these radios to build 
a metropolitan area network that 
includes a full duplex UHF digital 
repeater, a GBBPQ switch, and high- 
speed links to other areas. 


The Hardware 

The Kantronics D4-10 radio (not 
to be confused with the 2M DVR2- 
2) is a UHF radio designed for data 
transmission. Kantronics has opti- 
mized the D4 to move data at 19.2 
kilobaud within a 100KHz channel 
with a 60KHz receiver bandwidth. 
It’s crystal controlled on two channels 
nominally in the 430 MHz range and 
is rated at 10W output, although my 
Bird says more like 15. It has a 
<much> better receiver than the 2M 
DataRadio. 


The interesting feature of the radio 
is that it has a TTL level I/O port 
designed for direct FSK. TXD will 
modulate +/- 10KHz around the 
center frequency, and RXD is derived 
from a data slicer. The squelch cir- 
cuit is very fast (~2ms) and is avail- 
able as DCD on the connector. And 
not to worry — the TXD line is 
shaped, so the FSK isn’t based on 
square waves. The bandwidth is 
within FCC limits (100KHz) for the 
70cm band. 


Our Approach 

Since the radio is designed with 
digital levels in mind, my first test- 
ing with two of the beta models last 
March focussed on the simple ap- 
proach — using an 8530 SCC chip 
to generate HDLC frames and 
shoving those frames directly into the 
D4 TTL port. To my surprise, it 
worked! 


Since then, we’ve decided to base 
our network, at least for now, on that 
approach. If and when modems ar- 
rive that can do a better job, we'll 
probably use them, but for now the 
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savings of $100 per radio by not 
buying 19.2K modems outweighs the 
relatively small advantages the 
modems offer (mainly in more reli- 
able DCD, but even that’s open to 
question). 


Using the Ottawa PI Card 

Our first experiments used the 
Ottawa packet group’s PI card (a 
DMA driven, 8530 plug-in card for 
the PC bus). Interfacing them to the 
D4 is a snap — just wire up a five 
conductor cable between the two, set 
up NOS, and your'e in business. 


Interfacing the Data Engine 

However, the PI card only works 
in PCs, and (at present) only works 
with the KA9Q NOS software. We 
wanted to have an alternative packet 
generator available, so we focused on 
interfacing the DataEngine to the 
D4, sans modem. That also proved 
easy to do. 


Kantronics makes a small jumper 
board (for about $25) that’s designed 
to allow the DataEngine to work with 
an external modem. Just get one of 
those, jumper it as a type “A” modem, 
and add a CMOS chip to divide the 
RXClock signal by 32 to feed back as 
TXClock. 


More specifically, we used a 
CD4020 with the clock connected to 
pin 5 of the internal modem header 
and the divided output connected to 
pin 6. 12 volts is available on the 
jumper board; we used a 1K resistor 
and 5.1 volt zener diode to power the 
4020 chip with the necessary TTL 
level. The chip can be mounted “dead 
bug” style on the jumper board; the 
whole thing makes a very nice 
package. 


Software Speed Selection 

With either of these approaches, 
the actual data rate on the radio link 
is totally software-driven. It’s just 
a matter of what speed you program 
the baud rate generators to. We’ve 
moved packets at every supported 
rate from 110 baud to 28.8kb (28.8 
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doesn’t work very well, but it does 
work), simply by using the appro- 
priate “attach” command with NOS, 
or “modem” command with the 
DataEngine. 


Results 

First, these radios are as fast as 
Kantronics says they are. The PI 
card driver allows TXDelay to be set 
in lms increments, and we've found 
that a TXD of 4ms works. We're 
using 5ms to provide a bit of margin. 
Remember, this is <milliseconds>, 
not the (milliseconds times ten) that 
most TXD values represent. 


Our initial testing shows that very 
respectable throughputs are easy to 
achieve, at least across the room. 
Using NOS on 286 or better ma- 
chines, and a RAM disk to avoid 
mechanical slowdowns, we’ve con- 
sistently seen FTP file transfers of 
binary files go at 1600 or more 
characters per second between two 
PI cards. Note, though that this is 
on a totally clear channel, with all 
parameters set wide open. In the real 
world, neighborliness will require 
backing things off a bit. 


We do see some packets that don’t 
get acknowledged; the resultant re- 
tries and backoff can slow things 
down a bit. We’re investigating the 
problem, but at the moment don’t 
have any clues. 


We only began testing the combi- 
nation of a PI card station talking to 
a DataEngine station last night. The 
throughput there has been more like 
650-700 characters per second. We're 
not sure why this great a difference 
exists. Possibly the problem is that 
the DataEngine-to-host link on the 
serial port is running at the same 
speed as the radio link, that the 
computer just can’t keep up with 19.2 
serial data (we’re not using 16550s, 
so even though the machine is a 386, 
this is quite possible), or that the asy 
code in NOS is be less efficient than 
the PI driver. We're going to continue 
looking at this. 
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Digital Repeater 

We're turning two of the D4s into 
a digital repeater. Our input fre- 
quency is in the 420 MHz range, with 
output on 430 (a 10MHz split). The 
interface is actually very easy but it 
took a <lot> of trial and error to get 
things working. 

The problem in a nutshell is that 
although the digital port is advertised 
as “TTL”, it really isn’t. The PTT line 
is fairly standard — to key the ra- 
dio, bring the line to ground and sink 
about 5ma. 


However, the DCD, TXD, and 
RXD lines are all tied to op amp 
stages set up as comparators. Al- 
though they are biased to switch with 
TTL levels, we found that using 13.8 
volts is much more reliable. 


Also, it’s not obvious from the 
documentation but the FSK keying 
circuit actually has <three> states, 
not two. Grounding TXD shifts 
10KHz down, pulling it high shifts 
10KHz up, and something between 


will put out the nominal frequency. 
This cost us a lot of time — our first 
interface <seemed> to be modulat- 
ing the radio, and we could hear the 
data on the receiver’s speaker, but 
there was no RXD. It turned out we 
were shifting between -10 and center 
— enough deviation to make noise, 
but not enough to trigger the data 
slicer. 


Anyway, the answer was simple 
once we figured it out. We used a 
CD4049 hex inverter chip. Two 
cascaded sections provide PTT from 
the DCD input. Two more sections 
interface RXD to TXD. The chip is 
powered from the same 13.8 volt 
supply as the radios. 


The critical thing it took a while 
to figure out is that RXD <must> be 
tied high at the input to the inverter. 
Not doing this is what caused our 
indeterminate keying state. 22K 
between Vcc and RXD worked fine 
for us. DCD would probably also 
benefit from a pull-up resistor, but 
seems to work OK without one. 


Of course, you'll need extra cir- 
cuitry for control and time-out tim- 
ers. We’re also looking at ways to 
come up with a more reliable keying 
scheme; if the repeater is brought up 
by a rogue carrier, that will shut the 
whole network down. A circuit that 
detects a packet’s opening flags and 
trips a short timer (maybe 1 second) 
AND’ed with the squelch-derived 
DCD is probably the simplest an- 
swer. 


The repeater turn-around is pretty 
quick. We’ve been able to reliably 
send packets through it with a 
TXDelay of 10ms. Obviously, a hang- 
timer won't work in a system based 
on carrier-derived squelch, so the 
repeater output is indistinguishable 
from any other packet station. 


Repeater identification will be 
handled by the G8BPQ node that will 
be interfaced with the repeater. 


—John Ackermann, AG9V, and the 
Miami Valley FM Association, 
Dayton, Ohio”. Republication and 
distribution is no problem so long 
as credit is given. 


New Deal Available on UHF HTs 


Copied from Quarterly may 91 

About a year or so ago some NEDA 
member may recall how we were 
frantically buying up Wilson MH400 
UHF HT’s that we then put into links 
in a number of places. WA1TPP did 
an article for the Quarterly that 
showed us how to speed up and uti- 
lize the rig for packet as efficiently 
as possible and thus a number of 
links and special ports were put on 
the air as a result of these inexpen- 
sive little 2 watt hand held rigs. (The 
rigs only cost us about $80 each!) 


Well, it appears that the original 
vendor has struck yet another bar- 
gain with the folks at the Wilson/ 
Regency warehouse and managed to 
make another incredible bulk buy 
out. The deal this time is for UHF 
Regency MCPU-404 handhelds. 
These rigs are new closeouts that are 
4 channel, 4 watt crystal controlled 
handie talkies. While they don't 
come with antennas or batteries, the 
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vendor is selling them to us for the 
incredible price of $49.95 each plus 
shipping. If you should choose to use 
the rig as a portable and not canni- 
balize it for a packet link the vendor 
will sell you a drop in charger for 
$29.95 and batteries for $20 each. 
The batteries, by the way, are the 
same ones used by the Yaesu FT 203 
and 209 series radios, known com- 
mercially as a BP-4. The crystals it 
takes are HC-18u size with wire 
leads and the unit also has a factory 
installed jack that will take a plug 
in CTCSS board. 


Please contact the vendor directly 
as we will not have sufficient time to 
put together a NEDA bulk buy like 
in the past. He was kind enough to 
let us in on the lower pricing because 
of being on his preferred buyers list 
from the previous 30 or 40 odd units 
we bought before. Please move 
quickly on this as the vendor might 
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do something like raise the price or 
sell the whole lot to someone. The 
address: 


Torg's Electronics 

9280 W. 360N 
Shipshewana, IN 46565 
Phone: (219) 768-4406 


The proprietor is Mr. Torgeson so 
should you give him a call to get in 
on this, make sure to pass on the 
regards and best wishes for all the 
NEDA members already taking ad- 
vantage of the bargains he has pro- 
vided us in the past. Who knows? 
With a little effort maybe we can get 
Mr. Torgeson to get his own ham 
license!?! 


Oh, one more thing. Manuals for 
the unit should be readily available 
from Regency Electronics, or Torg’s 
can most likely provide you with a 
copy for a nominal extra cost. 


—Dana Jonas, WA2WNI 
Page 115 


Copied from Quarterly aug 91 

Bob, WB2QBQ owns and oper- 
ates the KNOX node in Knox New 
York. The node is located in and 
around his house. He is currently 
operating seven radios and anten- 
nas for the node itself and other 
radios and antennas for packet, FM 
and HF. The system has sprung up 
in a very short time, from a digi- 
peater in 1989 to a seven port node 
in the summer of 1991. Bob spends 
a great deal of his ham radio time 
tinkering with the radio and an- 
tenna systems as well as playing on 
packet. He also derives much en- 
joyment from having his system 
used by others as is evidenced by the 
amazing light display on the TNCs 
as the node is operating. Visitors 
to his site have remarked at how the 
action never seems to stop. 


Servers that are almost always 
using the KNOX node as a through 
path include the K2TR DxCluster, 
WA2TVE BBS, WA2PVV BBS, and 
WA2UMX BBS. 


Ss 


Kenwood Ts440 
28.195Mhz 
NY10DX-:user port 


suuemes ? 


Kenwood Tr7400 


144.91Mhz wireline 
KNOX:user port link 


CROWD node TNC 
(see text) 


KNOX:WB2QBQ Node 


Recent additions to the node in- 
clude a 900MHz 9600 baud link to 
Albany. The pre-existing 440MHz 
1200 baud link is still in place but 
will be reallocated once testing on 
the 900MHz link is competed. Bob 
expects to link to another site using 
the already in place 440 gear. 


A recent problem that Bob had is 
that his TS-440 HF radio has failed. 
As of this writing that radio is on the 
way to Kenwood but will hopefully 
be back on at or shortly after pub- 
lication date. 


Wireline Links 

KNOX node has two separate 
wireline links. The first connects the 
home station with the network node. 
Bob's home station is the third TNCs 
down in the left stack as seen in both 
the photograph and the diagram. 
The TNC has regular PacComm 
PMS software and is hooked to Bob's 
mini-tower PC. The radio 


port, however, is hooked di- eee 


rectly to the radio port of the #bkbn -> ALBANY iY 


BOB:WB2QBQ-9 TheNET 


Backbone port Hexipus 
Ties the 6 backbone 
port TNCs together 


— 
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~ 
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TNC. Stations who connect to KNOX 
and do a nodes list will see the BOB 
node. If you connect to the BOB node 
and then connect to WB2QBQ you 
will be connected to Bob's home 
station and the "*** Connected to" 
message will appear on the PC's 
screen. However, there are no radios 
in between WB2QBQ-0 and BOB: 
WB2QBQ-9. The circuit is made 
with a few 12 inch pieces of wire 
connected to the modem headers of 
the two TNCs. That connection is 
described elsewhere in this issue. 
(See Wireline Link). 


The other wireline link at the 
KNOX node is between the two 
separate node stacks. The right hand 
node stack consists only of backbone 
links and the DXKNOX node. The 
bottom TNC in the right hand stack 
is connected to the other five TNCs 
through the HexiPus™ but is not 
connected to a radio. Rather it is 
connected, via 
another wire link, 
to the bottom 
TNC on the left 
hand — stack. 


bt Kish IC3AT 
— H 223Mhz 
f OXKNOX: dedicated link 


a es Tm321- 
223Mhz 
#bkbn: —» SCH 


YY 


Kenwood 701 $ 
440Mhz 
#bkbn: — CHERRY 


WEoobers Pie Motorola MOXY oo) 3 
user station a wireline gekbnd ALBANY sees * 
User port Hexipus ink (see Bol e a 
pice tes tastier os CLSLILISSSSSS SSS SSL SLL SL p 
wireline for 
local access 
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WB2QBQ:KNOX node cluster 

This is a block diagram of the KNOX node. The TNCs are 
shown stacked in the same order as in the photograph on the 
facing page (on the bench). The radios are listed by product name. 
The pictorials of the radios and antennas are not accurate al- 
though the antennas shown as beams are in fact yagis. The omni 
antenna on the KNOX user port is actually a phased array of 
three yagis designed to form a pattern which favors Schenectady, 
Cobleskill, and Schoharie County. 
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Traffic that travels across the back- 
bones through Bob's house, but that 
is not destined for the KNOX node, 
travels from radio to TNC through 
the matrix, to TNC and back out the 
radio, without ever crossing that 
wireline link. The only traffic that 
goes through the wireline link is 
traffic that goes to the BOB node, the 
KNOX node, the NY10DX node or 
the CROWD node. This isolation 
between the node stacks allows the 
TNCs on each matrix to have less 
crowding in their communications 
between each other. More impor- 
tantly the wireline link concept al- 
lows very large node complexes to be 
built without regard to RS-232 
electrical considerations. A TNC is 
designed to hook up to one computer. 
Hooking it up to five other comput- 
ers (TNCs) through the matrix is 
wonderful for building networks but 
stretches the capabilities of the TNC's 
RS-232 port. Because Bob wanted 
to have four backbone links, a Dx- 
Cluster port, a CROWD, a user port 
on two meters and an HF gateway, 
plus the BOB node he had to break 


up the node cluster into two separate 
nodes. 


There is another advantage to 
having the wireline link between the 
TNCs: It makes a real nice light 
show!! 


CROWD node 

The first TNC on the left hand 
stack is the CROWD node. This TNC 
is plugged into the HexiPus™ matrix 
with four other TNCs but is not 
running TheNET software. Instead 
it's running NORD><LINK mini-conf 
software. It is fully TheNET com- 
patible but instead of handling net- 
work traffic, the CROWD node's 
purpose is to allow stations who 
connect a round table conference 
capability. The name CROWD was 
coined by WA2WNI in 1988 and has 
since been widely used for this 
function. There are CROWD nodes 
at many sites in the north east. Each 
CROWD node has a different callsign 
and usually only one CROWD node 
will show at any node site. If you and 
a few friends want to have a con- 
versation as a group you can all 
connect to CROWD at KNOX and 


each ham will see all of the text typed 
by each of the others. It's great fun 
and an excellent utility for emergency 
traffic handling. 


Simply connect to the KNOX node, 
then connect to CROWD. Now type 
slash W "/w" and the CROWD will 
give you a list of the other stations 
connected in and will announce your 
presence on the CROWD. If there 
is nobody on, hang in there and 
hopefully somebody else will check 
in during the two hours before you 
time out. If you type anything you 
reset the timer for another two hours. 
If you check in regularly you'll 
eventually start something and be- 
fore you know it you'll have a nightly 
CROWD crowd. Also check out the 
CROWD nodes at STMFRD and 
CANDGA nodes. 


Connect over to KNOX and play 
around with the R and N commands. 
For novices at TheNET network 
hacking you'll find the diagram very 
helpful for learning how those com- 
mands work and how TheNET net- 
works are put together. Have fun! 


—Dana, WA2WNI; Tadd, KA2DEW; 
Bob, WB2QBQ; and Bob, NQI1C (took 
the picture) 


Close-up view of the KNOX node TNC stacks 
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Gracilus PacketTen Network Node 


Copied from Quarterly aug 91 

Hi, I'm a nodeop of a Gracilus 
PacketTen based node here in the 
Chicago area. Yes, we are aware of 
NEDA. We've talked with various 
NEDA guys at the Dayton Packet 
Dinner, and know a little about how 
you do networks. We basically agree 
with the provisions you make to rid 
your network of what you call HTS 
stations, so that the network can 
perform reasonably. Our attempts 
to do that here have resulted mostly 
in Chicago style politics by people 
from outside the Chicago area, rather 
than an acceptance of the work that 
has to be done to make things work 
and a commitment to get on with it. 
Congratulations on your organiza- 
tional success. 


As you may know, K9NG is a local 
here. The local group in its early days 
recognized the need for development, 
and supported these efforts. The 
result was a 9600 baud network, 
using NET/ROM, a few months after 
NET/ROM was shipping. I developed 
modifications that matched the 
KING modem to Midland 13-509s, 
and we installed a 9600 baud NET/ 
ROM at the K9VXW-1 site and 
downtown Chicago. The downtown 
Chicago site uses, and continues to 
use, one of K9NG's original prototype 
modems interfaced to the Hamtron- 
ics 220 Rx and Tx boards, that he 
used for the tests published in his 
paper along with the FM-5. It's been 
in continuous operation since 1987 
at that site. Reports of G3RUH's 
early efforts to do 9600 baud, as re- 
ported in the British Packet News- 
letter electronic edition, and circu- 
lated around the Midwest by N8XX, 
were actually transported thru the 
operational KING Modem based 
NET/ROM network in the Chicago 
area. 


We came to the conclusions re- 
garding dedicated link network 
structure, about the same time the 
staggered link idea was published in 
GATEWAY, by the Florida guys. 
Considering it further, and the 
practical limitations of Midwestern 
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access to high performance RF sites, 
we did the system design for an idea 
which I've dubbed Cellnet. It's 
relatively easy to do networking in 
mountainous areas, where there are 
good RF paths at people’s summer 
cottages, with minimal tower and 
feedline. It's a little tougher in the 
Midwest where the 50 Kbuck tower 
only gets you 30 miles, reliably, and 
donated tower space is not always 
forth-coming for 3 or 4 antennas to 
be able to build networks like NEDA 
does. Cellnet solves these problems. 


Cellnet 

With a single dual band antenna, 
or an up/down mount 430 and 2 
meter antenna, 3 links and a LAN 
station can be operated. The links 
will be full duplex, dedicated point 
to point, which is about 6 times better 
throughput than the HTS protected, 
simplex CSMA technique used in the 
NEDA network, and for about the 
same cost. The PacketTen was de- 
veloped in response to the Cellnet 
concept, but its application has grown 
beyond that. See my paper in the 7th 
ARRL Computer Networking Con- 
ference notes. 


Recent History 

Anyway, based on that prehistory, 
here’s what happened about the time 
we finished up the main 220/9600 
baud stuff in the area: N4PCR moved 
to town. Additionally, KA9Q’s code 
was first being tried and the fact that 
it could handle so many ports, and 
simultaneous links made me think 
that it was time to start getting the 
Cellnet ideas I had down on paper. 
At Dayton that year, to my surprise, 
Karn and Dr. Death did a dog and 
pony show about a system very 
similar to the Cellnet ideas I’d had. 
So that really got me motivated to 
write it up and finish the system 
calculations. The excitement was 
contagious and N4PCR started 
working on a controller that would 
work with NET. His first attempt 
was good but just as he got it to work 
the 68302 chip became available. 
The 68302 is what the PacketTen 
controller is based on. He dropped 


This page copied from the NEDA Annual v3.0, 
March 1992. NEDA is Box 563 Manchester NH 03105. 


the old project and began a 68302 
project, formed a company, got two 
other guys to help him with it, and 
just started really working hard on 
it all. 


Configuration 
The PacketTen system has 4 
building blocks: 


¢ 2 versions of the processor card; 


¢ and 2 versions of the interface 

card. 
Processor Card 

There is a PC plug-in processor 
and another version that can stand 
alone or be plugged into the PC plug- 
in version. Each processor card has 
the 68302 on it which has three DMA 
ports, a 68000 CPU and a RISC co- 
processor for fast port operation, all 
in one chip. Additionally each 
PacketTen processor card has an 
SCC chip on it for two slower speed 
ports (up to 19.2Kbaud). The 68302 
ports can do up to a megabaud. The 
maximum throughput per processor 
is around 2 Megabaud. 


Interface Card 

The original interface board is a 
straight RS-232 port board. The next 
interface board they did is one that 
can handle the Kantronics versions 
of the standard 1200 baud and 
G3RUH modems right on the board. 
I think they might be coming up with 
a RS-232 interface board built as a 
plug in, with the same mechanical 
layout as the Kantronics modem, so 
they can do away with the original 
interface board altogether. 


PC based 10 port switch 

As I said, above, the two versions 
of the processor board can be con- 
nected. This makes a 10 port switch. 
The two processors, in such a switch, 
and the resident PC communicate via 
triple ported memory, for full per- 
formance between the three. 


Software 

The PacketTen comes with NOS 
software, ported to the 68000 in 
EPROM. A stand-alone PacketTen 
is the only NOS-in-a-box system 
available today. There is an 
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EEPROM for configuration memory. 
The KA9Q NOS has been expanded 
upon so that a NET/ROM-like user 
interface is there with full locked 
routes capabilities. The commands 
are different, being built into NOS, 
but the capability is there. I should 
know, I’ve been on his case to put 
them there, HI. The latest version 
of the code now has sorted NET/ROM 
nodes list too. 


Defined Neighbors 

By the way, we call locked routes 
defined neighbors in this part of the 
world so the NOS command that is 
used for that is the NET/ROM 
neighbor command. It is actually 
much easier to understand and 
communicate to others once you are 


up to speed with the Gracilus/NOS 
terminology. 


Memory 

The PacketTen has large 
memory for network node routing. 
It’s much larger than the 32K of 
RAM that NET/ROM can use on a 
TNC2. 


TCP/IP 

Since the PacketTen is running 
NOS, TCP/IP goes right through it. 
There's no need for NET/ROM-to- 
IP gateway stations if two IP LANs 
are connected together through 
links made up of PacketTen sta- 
tions. IP is truly the future for high 
performance packet. It will even- 
tually have the capability of auto- 


matic routing through hierarchal and 
determined routes. This combined 
system is powerful enough that world 
wide real time routing would be 
possible since beyond the ‘deter- 
mined’ routing horizon packets would 
be switched by hierarchies kind of 
like switching real time traffic like 
BBSs. 


Now, for non real-time traffic. 

(zzzz) 
—Don, WBSMJN@W9IUP 

Full info can be gotten on 

the PacketTen from: 

Gracilus 

623 Palace St. 

Aurora, IL 60506 


Use of GE Phoenix VHF Radios for Node 


Copied from Quarterly aug 91 

Recently I have received a couple 
of GE Phoenix VHF transceivers that 
I considered for use at the CLV site. 
What a deal! A generous ham friend 
asked if they might be useful in our 
cluster. I saw an opportunity to re- 
claim a couple of expensive dual- 
banders and return them to normal 
use. These Kenwood stalwarts have 
given meritorious service for two 
years without a hitch. However, now 
was the time to replace them with 
rugged and durable radios. 


The Phoenix is a 25 watt crystal 
controlled mobile unit whose small 
package lends itself well to stacking 
in tight quarters. It's tight front end 
and handy interface points make it 
a breeze to interface with TAPR clone 
TNCs. 


A service manual was obtained 
and crystal data was determined. I 
ordered them from International 
Crystal Manufacturing Co. for about 
$38.00 a pair. Once inserted they 
tuned up on frequency without any 
trouble. The Phoenix seems to have 
a bottom frequency limit somewhere 
around 145.00 MHz. All coils were 
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User Port Transceivers 


near the limits of their travel after 
tuning, however adjustments were 
positive with definite nulls and peaks 
where required. After about 1 hour 
tuning, the radio sprang to live with 
23 watts output and a receiver sen- 
sitivity of about .35uV. Absolutely 
perfect for a rig used as user port with 
a low gain omni antenna. 


I learned long that speaker audio 
is not necessarily the best for use 
with TNCs of the TAPR variety (or 
any other for that matter). I usually 
tap audio at the hot side of the 
receiver's volume control. This pro- 
vides an easily found tap point and 
results in great audio with minimum 
distortion and filtering. Lo and be- 
hold, after studying the service 
manual I found an excellent audio 
tap right there on the Phoenix's rear 
interface connector. It is labeled 
‘FLTRD VOL/SQ HI. As it turns out, 
this is audio after processing by a low 
pass filter that removes any CTCSS 
tones on the received signal. No 
problem for the TNC, as packet tones 
are not within this range. The fil- 
tered audio makes the job of the PLL 
much easier as it doesn't have to 
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discriminated low frequencies and 
their resulting harmonics. An added 
bonus is that the volume control no 
longer has an effect on the desired 
packet tones and can be turned down 
so as to keep the site quiet and turned 
up when making antenna adjust- 
ments or to check the path. 


The transmitter interfacing was 
straight forward. I simply connected 
the TNC transmit, audio and PTT 
lines to the radio's rear connector. 
Two audio inputs are available. I 
used the microphone input. I ad- 
justed the TNC level and the radio's 
deviation control for 3KHz maximum 
deviation. This resulted in a sweet, 
easily decoded signal with no dis- 
tortion. 


The GE Phoenix appears to be an 
excellent radio for our purpose and 
could be for you too. They are easily 
found on the surplus market and 
require very little effort to retune for 
packet service. They are well built, 
durable and should provide many 
hours of dependable service. 


—Charlie, NZCJ@WB1ICOY 
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SHERMN Node and Wireline Linking 


Copied from Quarterly aug 91 

The information presented on the 
facing page was transcribed from a 
block diagram and info/nodes listings 
supplied by Franklin. The existing 
setup as of the beginning of Sep- 
tember at the SHERMN node did not 
include the wireline link between the 
two matrices. Rather all of the radio 
TNCs were hooked up in one stack. 
Franklin supplied the following 
Routes listing: 
#GLIDA:N2JYG-11} Routes: 
> 1 SHERMN:N2JYG-3 230 1 
WPADXC :N2JYG-6 230 1 
#GLIDA:N2J¥G-14 230 20 
#GLIDA:N2J¥G-15 230 25 
ERIEPA:NM3G-2 230 2 ! 


#GLIDA:N2JYG-5 230 1 
#GLIDA:N2JYG-12 230 17 


Franklin also supplied the infor- 
mation that he used tc make the 
wireline link go. He said: 


The TNCs for the wireline link are 
working on the bench and operating 
to full speed. The RS-232 port is 9600 
baud as well as the radio port. 
TXDelay is set for 1 on the radio port. 
The EPROM was burned in as a full 
duplex TNC, Parm 33 set to 1. All 
other parms are standard backbone 
parms. The following mods were 
done to the TNC: 


¢ Set radio port to 9600. 
¢ Set RS-232 port to 9600. 


¢ Cut the jumper on the modem 
disconnected header from Pin 17 
to pin 18. 


Vv 
FRORPE 


¢ Use a 3 wire jumper about 12 
inches long. 


¢ Connect Pin 17 on TNC A to Pin 
19 on TNC B. 


¢ Connect Pin 19 on TNC A to Pin 
17 on TNC B. 


¢ Connect grounds on the two 
TNCs together. 
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Franklin asked that I supply the 
info on connecting DCDs on the two 
TNCs as his setup didn't do this. 
Under heavy load collisions would 
occur without DCD hooked up. This 
is important. Also the LED for DCD 
won't work. Here is the required 
circuit: 

Both Tiny 2 and MF J: 


1 Movethe DCD select jumper to 
external DCD. Make sure the 
DCD light works once you are 
done! 


2 Usea 74HC04 Hex inverter IC 
(74LS04 is OK substitute). 
Radio Shack part #276-1802 
looks right. Make sure it's a LS 
or HC part though. You never 
know from those guys. 

3 Connect pin 14 of the IC to +5 
in the TNC. Pin 14 of another 
14 pin 74 series chip in the TNC 
is a good place. 

2 Connect pin 7 of the chip to 
Ground. Again pin 7 of another 
14 pin 74 series chip is good. 

3 Connect pin 5 of the modem 
header of TNC A to pin 1 of the 
chip. 

4 Connect pin 5 of the header of 
TNC B to pin 3 of the chip. 

Tiny 2 steps: 

5 Connect pin 5 of the 5-pin DIN 
from TNC A to pin 4 of the chip. 

6 Connect pin 5 of the 5-pin DIN 
from TNC B to pin 2 of the chip. 

7 Connect pins 5, 9, 11 and 13 of 
the chip to pin 7 of the chip 
(Ground). This ties all unused 
pins. 

MF J 1270B steps: 

5 Connect pin 5 of the 5-pin DIN 
from TNC A to pin 8 of the chip. 

6 Connect pin 5 of the 5-pin DIN 
from TNC B to pin 6 of the chip. 

7 Connect pin 2 of the chip to pin 
5 of the chip. 
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8 Connect pin 4 of the chip to pin 
9 of the chip. 


9 Connect pins 11 and 13 of the 
chip to pin 7 of the chip 
(Ground). This ties all unused 
pins. 

Construction method. 

I must warn you that I'm a soft- 
ware weeny, nota technician. That's 
why I do newsletter editing and not 
PC board design and radio modifi- 
cation!! | 


What I do for a simple quickie 
operation like this is run the wires 
from the B TNC into the back of the 
A TNC through the TTL interface 
hole. Fan the 14 legs of the chip out 
flat and glue the chip to the top of the 
Z80 CPU or the 32K RAM chip. Tie 
the wires coming into the TNC to one 
of the legs of the regulator IC as a 
strain relief. Now run the wires to 
the chip. 


Modification for using MFJs in- 
stead of PacComm. The only differ- 
ence between the two brands that we 
are concerned with is that the DCD 
level is inverted. So the MFJ re- 
quired an extra inverter stage on the 
74HC04. 


Now turn it on and let the smoke 
out! 


Back to Franklin. 


The only difference between the 
MF and the Tiny 2 is the port speeds 
are set for 19200 in the Tiny 2 and 
9600 in the MFJ. Because I do not 
use Tiny 2s I am not sure of any other 
mods for that TNC but remember to 
do the standard mods for the MFu, 
I.E.: Clock, U3 etc. 


73's and type at you later, and pray 
for peace in the world. 
—Franklin Werren - N2JYG 
editing and graphics by KAZDEW 
Editor's note: Wireline linking is covered 
in more delail in the “Burning EPROMs 
and putting it all together” section of the 
TheWVET Resource Manual in this docu- 
ment. This article is still good because it 
gives an excellent pictorial of wireline link- 


ing in use. 
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Illustration of the Sherman NY node owned by Frank Warren, N2JYG 
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NOS PARMS Table 


Copied from Quarterly aug 91. This file roughly indicates the NOS equivalents of various TheNET PARMS. 
Please pay careful attention to the footnotes, some of them are important. 


TN2.08 Description NOS 

1 min quality for update “netrom interface ax0 IPROCH 230” note 1] 
2 HDLC channel quality N/A (fits in with #1) 

3  RS-232 channel quality N/A (fits in with #1) 

4  obso count initial value fixed at “5” [note 2] 

5 min obsolescence for broadcast node is broadcast until it drops off 

6 nodes broadcast interval “netrom nodetimer” 

7 FRACK not sure 

8 MAXframe (layer 2) "ax25 MAXframe” 

9 _ link-layer retries "ax25 retries” 

10 digipeat "ax25 digipeat” [note 3] 

11 validate callsigns N/A 

12 host mode connects N/A 

13. TxDELAY “param ax0 1 15” [note 4] 

14 broadcasts on/off “netrom benodes ax0” turns on broadcasts for the interface named ax0 
15 pound node propagate what does this mean? 

16 connect command enabled set through password file /ftpusers” 
17 destination list max size dynamically allocated 

18 Time-to-Live initializer “netrom ttl” 

19 transport layer timeout “netrom irtt” [note 5 - neato!] 

20 transport layer retries “netrom retry” 

21 transport ack delay “netrom acktime” 

22 transport busy delay “netrom choketime” (maybe? not sure) 
23 netrom window size “netrom window” 

24 congestion control (not sure) 

25 non-activity timeout a 

26 P-persistence “param ax0 2 128” [note 6] 

27 slot time “param ax0 3 xxx” xxx = slot ime 
25 te (got to look this one up, book t work) 
29 t3 timer “ax25 t3 xxx” (zero means never”) 
30 N/A 

31 N/A 

32 N/A 

33 duplex “param ax0 5 xxx” 


One thing that NOS has that TheNet doesn’t have: 
netrom verbose [ON | OFF] 
its nodes list, only advertise its presence. 


if “off’, on a broadcast the switch will only broadcast itself; it will not repeat 


Disclaimers 

(1) I didn’t do it. 

(2) This list isn’t totally complete, so if you have questions **ASK** 

(3) Watch out for units. For example, PARM 21 (ACKTIME) is in seconds, but in NOS “netrom acktime” 
is in milliseconds. This can be a serious problem if you've got retry. timer units out of whack. Look it 
up. 

(4) If you’ve got sysop privileges, you can remotely sysop these parameters, with the exception of those that 


(2) 


(3) 
(4) 


can only occur once on initialization (like setting the incoming route quality) 
Notes: 
(1) This can only be done once, in autoexec.net. In the example, it sets interface ax0 as the node mnemonic 
“TPROCH” with route quality 230. 

In NOS, the obsolesence counters are decremented on a totally different timer than the nodes broadcast 
timer. Since this number is fixed at 5, if you want it to drop a node after 2 hours you would set “netrom 
obsotimer” to 2 hours divided by five, or 1440 secs) 

You may never digipeat “through” level three 

ax0 is the name of the NET/ROM interface. The example is 150ms. 


(5) Thisisa really neat feature of NOS. The initial round-trip-time (netrom irtt) is the “default” time in which 
you expect an ack back. After a few packets, NOS starts remembering what the real time is. Thus, after 
it has been running for a few hours, it will learn to expect a response from a close node in a much shorter 
time than a far away node. A fudge factor is added to this round-trip time internally. Because of this 
feature, setting the transport retry limit to 1 is not practical; I have been using 3 and think that is fair. 

(6) ax0 is the name of the interface we’re programming. The ‘2’ is the KISS parameter code for persistence. 

—Chris ot, WZ2B 
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Installation of the MF.J 2400 Baud Modem in the Tiny-2/Micropower-2 


Copied from Quarterly aug 91 

While performing this installation, 
normal anti-static procedures should be 
followed. Avoid carpets and plastic 
chairs (plasti¢ chairs are really bad) as 
a start. 

1 Remove the nylon standoffs from 
the modem so it will fit on the TNC. 

2 The MFJ2400 has provisions for an 
on board negative voltage regula- 
tor. A 79C05 (-5V, 3 terminal volt- 
age regulator in a TO-92 package) 
should be installed at VR1 and the 
trace between pins 2 and 3 of CN2 
should be cut and a jumper should 
be installed between pins 1 and 2 
of CN2. This now allows the 
MFJ2400 to be powered from -12V 
rather than -5V. 

Steps 3 thru 14 will have to be per- 
formed to get the TNC and modem to fit 
into the case, however I recommend 
getting it to work first by skipping to 
step 15 and simply plugging the modem 
directly onto the TNC’s modem discon- 
nect header (MFJ2400-CN1 to TNC- 
J5). Pin one at CN1 on the modem 
should be aligned with pin one at J5 on 
the TNC. 

3 Remove the Connector at CN1 on 
the MFJ2400. This is necessary 
since the shape of the PCB does not 
allow it to be plugged directly into 
the TNC and still fit in its case. Be 
careful not to break any traces. 
Clear out the holes so wires can be 
soldered in place later. 

To remove this connector, it may be 
easiest to break its plastic housing into 
small pieces with a wire cutter. The 
plastic housing usually can be pulled 
away from the PCB leaving only its 
contacts soldered in the PCB. These 
contacts can then be pulled out one at 
a time while applying heat where they 
are soldered. 

4 Remove the connector at J5 on the 
TNC for the same reason as item 
#1 above. Clear out the holes so 
wires can be soldered in place later. 
To remove this connector, it may 
be easiest to apply heat to the sol- 
der side of the PCB at one of the 
pins. After the solder softens, pull 
lightly on the pin from the other 
side, it should pull out from the 
PCB and plastic. Repeat for all the 
pins. 

For steps 5 thru 14, #24 gauge solid 
conductor wire is recommended. It is 
best to solder the wires in place on the 
modem first, with .75 inch of insulation 
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from the bottom of the modem. Long stripped portions (2 or 3 inches) of the wire 
past the insulation will make insertion into the TNC easier. 


5 Wire pad at MFJ2400 CN1 pin 6 to pad at TNC J5 pin 6. 

6 Wire pad at MFJ2400 CN1 pin 11 to pad at TNC J5 pin 11. 

7 Wire pad at MFJ2400 CN1 pin 12 to pad at TNC J5 pin 12. 

8 Wire pad at MFJ2400 CN1 pin 13 to pad at TNC J5 pin 13. 

9 Wire pad at MFJ2400 CN1 pin 14 to pad at TNC J5 pin 14. 

10 Wire pad at MFJ2400 CN1 pin 15 to pad at TNC J5 pin 15. 

11 Wire pad at MFJ2400 CN1 pin 16 to pad at TNC J5 pin 16. 

12 Wire pad at MFJ2400 CN1 pin 17 to pad at TNC J5 pin 17. 

13 Wire pad at MFJ2400 CN1 pin 18 to pad at TNC J5 pin 18. 

14 Wire pad at MFJ2400 CN1 pin 20 to pad at TNC J5 pin 20. 

15 Cut the trace between pins 11 and 12 of J5 on the TNC. 

16 Cut the trace between pins 13 and 14 of J5 on the TNC. 

17 Cut the trace between pins 17 and 18 of J5 on the TNC. 

The following traces should not have been cut on J5 of the TNC: 
Traces between pins: land 2; 3and 4; 5and 6; 9and 10; 19 and 20 

Using the supplied cable which plugs into CN7 on the MFJ2400 perform the 

following: 

18 Cut one of the connectors off the supplied cable, strip and tin the ends of the 
unterminated leads. 

19 Solder the Orange wire to the negative (-) side of C24 (CN7-3 Ground) 

20 Solder the Yellow wire to the 5V output (pin 3) of U5 (CN7-4 +5) 

21 Solder the Green wire to the side of R6 which is connected to U15. (CNT-5 - 
voltage) 

22. Solder the Red wire to pin 4 on the radio connector.(CN7-2 RX Audio) 

23 Remove C27 from the TNC and solder the Brown wire to the C27 pad which 
is connected to R12. (CN7-1 TX Audio) 

24 Connect a wire from R37 where it connects to T5 on the MFJ2400 (the end 
closest to IC6) to Ground (Modem enable wire). Grounding this wire enables 
the 2400 baud modem. 

25 The Radio baud rate setting on the Tiny/Micropower should be set to the 2400 
baud position 

26 Place some insulating material between the Modem and the TNC to prevent 
shorts. (note - anti-static foam is not an insulator. I have seen people use it 
as such which causes some real interesting problems) 

27 Clip approx 1/8 inch off the ends on the pins at CN6 on the modem. They are 
a little long and will short to the case unless cut. 

28 3 should be bent over so its tab does not short to the case. 

29 To hold the modem in place, a couple of pieces of buss wire can be wired from 
the ground plane on the component side of the modem along the edges (scrape 
away the solder mask) to the ground traces along the edges of the Tiny/ 
Micropower. 

This completes the installation. 

NOTES: 

To restore 1200 baud operation, first the Modem enable wire connected to R37 
on the MFJ2400 should be disconnected from ground and be left to float (Item 24). 
Second C27 needs to be reinstalled (Item 23), but the Brown wire need not be 
disconnected since the 2400 modem goes to a high impedance output. Finally switch 
the radio baud rate setting back to 2400 baud. Proper wiring of a 3PDT switch to 
perform the above would allow switch selecting 1200 or 2400 baud operation. 

For proper 2400 baud operation thru the radios microphone jack proper setting 
of the transmit deviation is necessary. 3.5 kHz is recommended. The transmit 
audio level can be adjusted by using the R12 on the TNC and if the output range 
is not sufficient or touchy the jumper can be moved on CN6 of the MFJ2400 or 
change the adjustment range (see MFJ2400 baud manual) The potentiometer 
on the MFJ2400 can also be used to adjust the transmit audio level as well. 

The TNC which originally would function with input voltages from 9 to 14 volts 
will now only work with 11 to 14 volts input. This is because the negative voltage 
picked off of U15 on the TNC will not be enough for the -5V regulator on the mo- 
dem. When this happens the modem stops functioning although the TNC will still 
function normally over the RS-232 port. 

—Bill Slack, NX2P 
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NEDA and Servers On 2 Meters 


Copied from NEDA Quarterly feb 91 
This article addresses the question 
of “What is NEDA’s stand on serv- 
ers using 2 meter user ports to access 
the NEDA network”. A server is any 
station that is on the air as a service 
to users other than it’s owner. This 
includes PBBSs, DxClusters, TCP/IP 
gateways, DOSgates, CD-ROM 
callbook servers and any station that 
sources large volumes of data to other 
stations across the network. 


NEDA network participants vol- 
untarily agree to a consistent set of 
technical guidelines. These guide- 
lines only specify the software run- 
ning in the node TNCs at each NEDA 
node site and the interlinking 
methodology between nodes. How- 
ever, at least one of the club’s tech- 
nical documents describes how det- 
rimental a station sourcing high 
volume data to a user port can be on 
users. Let me restate: 


On a given node if the server has 
it’s own uplink on 440 and the users 
access the server via the 2meter user 
port there will be very few collisions 
even when loading is at maximum. 


If the server is accessed via the 
2meter port (the server is on the 
same 2meter freq.) then there will 
inevitably be collisions. If the user 
port is fully loaded by users access- 
ing the server or by other server ac- 
tivity then there will be lots of colli- 
sions and efficiency will be no more 
than 19% and sometimes as bad as 
0%. } 


Server ops who do tie into their 
local network on 2 meters will defi- 
nitely degrade the performance of 
users at that 2 meter port. The us- 
ers will also hamper communications 
of the server with the network. Ifthe 
server were to find a dedicated access 
into the network the server and us- 
ers would both benefit in efficiency, 
and more fun would be had by all. 
While servers may share a frequency 
with users, functionality will be far 
below that of servers on dedicated 
links to the network. If the server 
is offering a valid service there is no 
reason in the world that those ben- 
efiting from same couldn’t help fund 
the dedicated link for the server! 


It is up to the node sponsors to 
determine their own policy to ap- 
prove or disapprove of server activ- 
ity on the frequency of the node’s user 
access port. It is up to the potential 
server’s operator to respect the 
wishes of the sponsor of the node. 
This policy is no different that the 
manner in which voice repeaters are 
operated. 


The more fun that is had and the 
more efficiency with which the net- 
work is run, the more the network 
will grow and the more different 
kinds of services will be available. 
The bigger the network is, the more 
good people there are working to- 
gether for a common goal. That is 
NEDA’s position. 


1Binder R. Abramson, N, Kuo, F., 
Okinaka, A., Wax D. (1975), 
‘ALOHA packet broadcasting - a 
retrospect’, AFIPS Conference 
Proceedings, 44, 1975 NCC, 203- 
215. ** reference and information 
source for the Quarterly was taken 
from “The Data Ring Main” by 
Flint. Published by Wiley. 


—The NEDA Board of Directors 


Notes about the 9600 G3RUH modems 


Copied from Quarterly aug 91 

You may or may not have known 
that voltage variations on the 12V 
line affect the modulation level out 
of the NB96. This has caused some 
problems in some of the stuff I have 
done. A voltage change from 12 to 
13.8V can easily change the trans- 
mit deviation (when fully interfaced 
to radio) from 3KHz to 5KHz. This 
is something to be aware of when 
setting up the 9600 BPS modems 


ITheard a report about a fix, which 
has made a big difference for some 
UoSAT ops, but with no cause. I 
looked into it, and I can see why. 
Here it goes: 


On the NB96 card (internal or 
external) a reference voltage is de- 
rived off the 12V power supply by a 
resistor divider. This divider consists 
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(including the NB96) 


of two 100K with a .luF capacitor 
from the junction of the resistors to 
ground. The resistors in question are 
RS1-3 and RS1-4. This provides a 
6V reference. The capacitor and 
resistor values set a time constant of 
.005 seconds which filters out high 
frequency noise (above 200 Hz) which 
may be present on the 12V line. The 
200 Hz significantly below the 
modulation rate so that is good, but 
it is too high to provide isolation from 
60 or 120 cycle ripple from a poorly 
regulated power supply, and it pro- 
vides no isolation from the low fre- 
quency voltage changes which occur 
when the transmitter keys up. Ihave 
noted that I have has to set 
TxDELAY much longer than I would 
have expected in some installations. 
This may be the root cause of that. 


This page copied from the NEDA Annual v3.0, 
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That resistor divider is buffered 
thru a op-amp follower to convert it 
to a low impedance suitable for use by 
the remainder of the circuitry. This 
is good or it would be much worse, but 
still any fluctuations in the reference 
on the high impedance side of the op- 
amp will be faithfully duplicated on 
the low impedance side. Since that 
reference is used by all the analog 
circuitry, and noise there degrades the 
overall system performance. 


The fix to this problem is to replace 
RS1-3 with a 6.2V zener diode (anode 
goes to gnd). I would recommend 
replacing RS1-4 with a lower value 
resistor to increase the idling current 
of the zener minimizing voltage 
swings. Something between 1K and 
5.1K should do nicely. Also adding a 


larger capacitor in parallel with C24 
Continued "» 


N.A.P.R.A. Notebook v1.0 
© NAPRA 1992 


Copied from Quarterly aug 91 

I did some tests upping the clock 
speed on the Tiny-2 TNC. I suc- 
cessfully got them to work with a 
9.825 MHz clock which is 2x the 
normal clock. Since the baud rate 
clocks are also derived off of the main 
system clock, the 19.2 position now 
generates 38.4Kbaud. As higher 
speed links are more common, and 
the number of these links at one site 
increasing, the normal capacity of the 
9600 or 19.2K RS-232 link between 
the TNCs is becoming increasingly 
taxed. 38.4 may be a viable solution. 


One of the driving factors behind 
the test is the poor high speed per- 
formance of the standard TNC code. 
Doubling the clock speed should go 
a long way to helping. Of course all 
the timing parameters are now only 
one half their original value. 


A TNC modified as such does not 
have the same computing power of 
a “data engine” or PC, however us- 
ing it for high speed packet does 
become viable. Can you call 38.4 high 
speed? Some people seem to thing 
56K is a magic number. Sort of like 
9600 is magic compared to 4800 al- 
though 4800 is quite respectable. Of 
course some people would say any- 
thing less than a 1 megabit is low 


Tiny 2 TNCs at 38.4Kbaud 


speed. In my mind, 300-2400 is 
standard (slow) speed packet. 4800- 
19.2 medium speed, and I would call 
38.4 to 1 Mbaud high speed. Above 
that can be very high. All is relative. 


Here is an idea. The GBRUH 
modems can operate above 9600 by 
changing some of the filter compo- 
nents. In fact I am told they would 
work much higher including 38.4K. 
So now we haye a TNC with a 2x 
clock, and set the radio baud rate to 
the 19.2 position so it is actually 
operating at 38.4K We modify the 
G3RUH modems filtering so it will 
do the 38.4K. So far so good, the 
proceeding is pretty straight forward. 
Next we take one of the Tekk KS-900 
data radios. We change some of the 
front end filtering on the transmit 
side so it will pass higher frequen- 
cies than it was originally designed 
for. Now the only limiting factor is 
the 20KHz IF filter of the radio. We 
need more receive bandwidth. It is 
relatively easy on the transmit side, 
but we need to find a wider IF filter. 
Well I was thinking, what about FM 
broadcast receivers? They must use 
a wider IF and in fact, it should be 
about what we need. Perhaps a bit 
wide, but it should do it. What do you 
think? Basically a 38.4K link for the 


cost of a 9600 baud link plus a few 
extra parts and some work. Of course 
with the wider bandwidth range 
would be reduced. I am making some 
assumptions about the ability to 
modify the radio which is where Iam 
not sure about. Any comments? 


All the new Tiny-2s use 
6MHz parts, but older 
units may use slower 
speed parts which means 
they could not be modified 
with the higher speed 
clock. In fact there is no 
guarantee that new units 
will work at the high 
speed. I only made the test 
on two units both of which 
worked fine. Also after 
upping the clock speed, 
tests should be made with 
the TNC at various tem- 
peratures to make sure it 
will function reliably. 
—Bill Slack, NX2P 
leditor 1/4/1993. PacComm now sells a 
Tiny-2 Mark 2 tor the same old price but 
it comes standard with 384Khaud and 
10Mbhz selectable oscillator. t's also us- 
ing low power CMOS gates now so its 
only 30mA current @12V] 


would be a good idea. A 5.0uF ca- 
pacitor would maintain the same 
time constant if a 1K resistor were 
used instead of a 100K. 25uF would 
provide some immunity to 60 and 120 
cycle stuff, but that starts getting 
big.. The Zener works well on the 
lower frequency stuff so the time 
constant between the resistors and 
capacitor is much less important so 
it is not worth getting too hung up 
on the capacitor. C24 should be left 
in the circuit as a .luF. That provides 
isolation from the high frequency 
stuff which the Zener is not good on. 
RS1-3 and RS1-4 are parts of a re- 
sistor SIP network so it is not simple 
to just remove these without affect- 
ing the other resistors. Since the 
impedance of the reference circuit is 
being dropped so low with the above 
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changes, these resistors can be left 
in place with little effect. 


Note: the above note/modification 
not only applies to the PacComm 


units, but probably all the GJRUH 
based modems since the above 
problem is in his original design. 


—Bill Slack, NX2P 
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The Exposed Receiver Syndrome 


Copied from Quarterly aug 91 

By now you have probably heard 
of the Hidden Transmitter Syndrome 
(HTS), and NEDA’s policy of insist- 
ing that all backbone links be HTS 
free. The hidden transmitter prob- 
lem is the scourge of low cost back- 
bone attempts. A related but less 
well known problem, which can have 
a detrimental effect on hilltop User 
Ports, is the Exposed Receiver Syn- 
drome (ERS). The Exposed Receiver 
is the receiver at a User port that 
hears much more than it needs to; 
it is “exposed” to signals working 
other nodes in distant communities. 


The problem with nodes experi- 
encing ERS is that User port TNC 
defers to the distant signals, waiting 
unnecessarily before sending. The 
TNC does not realize that these other 
signals that it hears are so distant 
that it could safely transmit to its 
local users without causing inter- 
ference to the distant stations. In the 
meantime, the local users’ TNCs may 
retransmit because of the unexpected 
long wait for an acknowledgment. 


Split UHF Frequencies for 
Maximum Band Utilization 


Copied from Quarterly nov 91 


This further adds to congestion on 
the channel and slows things down. 


What does this mean for you, the 
operator (or future operator) of a 
NEDA node? First, this shows the 
need for small, local coverage nodes 
(“nodes in homes” as Tadd calls it). 
As activity grows, the packet network 
will benefit from a “cellular” ap- 
proach, where several local coverage 
nodes are linked together via a HTS 
backbone, rather than trying to cover 
the same area with one massive 
coverage mountaintop node. Second, 
the User port frequency should be 
chosen to reduce ERS from other 
nodes on the frequency. This means 
that wide coverage area nodes should 
be on less popular frequencies, as 
opposed to say 145.01. High power 
output and high gain antennas may 
actually hamper the usefulness of 
your node rather than enhance it. If 
the node is not centered on the in- 
tended coverage area, then use a 
directional antenna to target your 


audience and limit your exposure. 


Phil Karn, KA9Q, proposed a 
software solution to this problem in 
a paper at the last ARRL Computer 
Networking Conference. This may be 
a long term solution, but it would not 
be compatible with existing systems 
now. 


Consider adding a CTCSS en- 
coder/decoder to the node. If 2 nodes 
sharing the same frequency each had | 
CTCSS encoders, they could each 
sense the presents of the sub-audible 
tone from the other node and then 
squelch the receiver. (The sense of 
the squelching is the reverse of what 
is usually done with CTCSS). When 
a local user started transmitting he 
would capture the receiver at the 
local node, thus ending the sub-au- 
dible tone and allowing the receiver 
to open. Since each nodes’ receiver 
would stay squelched whenever the 
other node transmitted, the nodes 
would never end up waiting for each 
other before starting to send. 


—Rich Place WB2JLR 


G8BPQ/Hexipus Problem Note 


Copied from Quarterly nov 91 


For all versions of GBBPQ you must run the port in 


At the VE2RM:WQC node site I have installed a packet 
repeater. The repeater site is operated by the VE2RM 
radio club. Because of the split frequency (5MHz) nature 
of the repeater I was limited to installation of UHF links. 
I proposed that instead of running point to point back- 
bone links on UHF simplex frequencies, which are scarce 
at the site because of the repeater, that we run our point 
to point links on half-duplex channels whose pairs are 
adjacent to one another. Thus as the repeater transmits 
on 446.025 and receives on 441.025, the links would all 
transmit in the region of 446 and receive in the region 
of 441. This implies that the sites we're linking at must 
also be using a split, half duplex, method of UHF 
channalization. This plan allows for many UHF links 
in and out of the same site. 


The idea has been implemented now in both the 
Montreal and Quebec metro regions and seems to be 
without flaw. 


—Burt Lang, VEZBMQ 
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half duplex to get it to talk to the active coupler and 
Hexipus. This is not documented correctly in BPQ until 
version 4.04. 


-K1MEA, Jim Wzorek 


Nice and Direct 


Copied from Quarterly nov 91 
This is the info text on the Watertown NY node. 


WATERT:WB2QU0-5} } 

Watertown NY in Jefferson Cty 

144.97 user LAN! 

NO DIGIS OR SERVERS ON 144.97 PLEASE! 

Set your DIGIPEAT OFF 

Talk to KB2DAJ about adding to the network 
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Screamers! 
or 


The Network ... What is it? 


Copied from Quarterly feb 91 

How many times have you tried 
to explain to a newcomer what the 
Network is all about and how 
NEDA'’s version is superior to a string 
of digi’s or a single frequency ar- 
rangement of nodes only to have that 
person walk away from you after 5 
minutes or go glassy eyed and 
mumbling to themselves. We all 
have at one time or another and it 
hurts to realize that many packeteers 
have little or no idea of what goes on 
in the network. If you think about 
it for a moment it isn’t that much 
different than people’s approach to 
the phone system in that everyone 
uses it and can detect the slightest 
decrease in performance but not 
many understand how it works. 
Next time you try to explain the 
system’s workings to someone think 
about how NEDA evolved and your 
explanation will make far more 
sense. 


Going back to the earliest recorded 
history of packet we find reference 
to a Neanderthal race of pseudo techs 
that developed a method of commu- 
nications that consisted of placing 
individuals, one after another, on a 
string of mountaintops. Each was 
within earshot of the next and each 
individual was equipped with a 
magaphonelike gourd that was used 
to enhance his directivity and to in- 
crease his unidirectional gain. Each 
person was capable of repeating what 
he heard but only the first and last 
had a check back memory, intelli- 
gence was a rare commodity in those 
days. Messages would move from 
one end of the mountain chain to the 
other through a series of shouts and 
grunts one to the next ending hope- 
fully with a final shout to the end 
mountain. What with screaming 
beasts in the jungle below, erupting 
volcanos and violent electrical storms 
the message was often lost some- 
where between start and finish. This 
would result in a series of screamed 
“What did You say?” — “Beats me, 
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let me check with the next guy “ex- 
changes that would eventually return 
to the beginning Mountain top and 
then the process would repeat itself. 
If one was patient eventually all 
pieces of the message would arrive 
at the end mountain and communi- 
cations was deemed to have taken 
place. The age of the DIGIPEATER 
had come and communications 
limped along for several years in this 
fashion. 


For some this approach seemed to 
be a little clumsy and finally the 
question was asked “What if each 
person on each mountain top had a 
check back memory?” The mountain 
tops quivered as this flash of bril- 
liance reverberated through the 
system. “With individual memory we 
wouldn’t have to restart missed 
message segments from the first 
mountain but rather we could correct 
mistakes or repeat portions missed 
between any two mountains at the 
point where the problem occurred.” 
It didn’t take long for people to realize 
that this was a vast improvement 
over the aging DIGIPEATER ap- 
proach. One local leader of an es- 
pecially primitive tribe of people in 
what is now NY State was heard to 
say “I Node There was a better way 
to get thin dun” and thus the Age of 
the Node was born. 


The new system grew in leaps and 
bounds and soon there were nodes all 
over the place, all screaming and 
grunting from there respective 
mountain tops at the top of their 
lungs and remembering things be- 
tween screams and passing traffic 
hither and yon. As time when on 
more and more nodes appeared 
people started to notice that mes- 
sages were taking longer and longer 
to get from one end of the system to 
the other and once again people 
started to wonder if there was a 
better way to get things done. A 
young chief with long flowing golden 
tresses journeyed to the top of one of 
the mountains and after listening for 
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a few moments to the cacophony of 
grunts, screams, hiccups and burps 
exclaimed “This noise is awful, I can’t 
tell one message from the next! We 
NEDA better way of doing things”. 
Yup, you guessed it. This was the 
start of the NEDA Network and it 
represented another great leap for- 
ward for communications. 


The young chief reasoned that the 
problem with the Old Node system 
was that with so many Nodes on so 
many mountain tops all screaming 
at the same time individual messages 
were being lost in the roar. He re- 
turned to his village and in a stroke 
of genius discovered that certain 
member of his tribe could only hear 
low tones while others could only 
hear middle tones and some could 
only hear high pitched tones. He 
then selected other members of his 
tribe with low, medium and high 
pitched screams and he started to 
build his new network. He placed 
pairs of screamers on mountain tops 
with different pitched voices and 
along side of them placed pairs of 
tribe members with different hearing 
responses. He found that by using 
this approach they could be receiv- 
ing a message form a distant 
mountain and at the same time be 
sending one to the next mountaintop 
without the two processes interfering 
with one another. Once again the 
communication rate bounded up- 
ward. 


Well many years have since 
passed and the young chief is now old 
but his work goes on. Though careful 
selection some mountain tops have 
6 or more pairs of screamers and 
listeners. It is rumored that some 
mountain tops are populated with 
FASTER screamers and messages 
are moving more rapidly than ever... 


I hope that this historical per- 
spective helps you the next time 
someone says “Tell me about NEDA”. 


HS 
The Old Packeteer 
Page 127 


G8BPQ Version 4.04 HexiPus™ Interface Bug 


Copied from Quarterly aug 91 

We had a problem interfacing 
G8BPQ’s switch software to our 
HexiPus™ which everyone needs to 
know about. As you probably aware, 
we have had numerous successes in 
mating a BPQ equipped computer 
direct to a node stack. There now 
appeared to be a “difference” in BPQ’s 
handling of such things in his latest 
version, 4.04 causing the BPQ code 
and the node stack to stop talking to 
one another. The previously released 
version of BPQ (version 4.03a) 
worked just fine. Upgrading to 
version 4.04 using the same config 
file (there doesn’t appear to be any 
difference in BPQCFG from 4.03a to 
4.04) brought everything to a halt. 


Reinstalling 4.03a, resurrected the 
complex entirely. 


A letter from G8BPQ to N2JHJ 
dated December 12 1991 said that 
a fix in 4.04 that allows for telephone 
modem use made it necessary to 
have the CTS connected to the RTS 
on the PC side of the HexiPus™ - 
PC interface cable. The fix is to tie 
CTS to RTS at the PC's connector. 
This will allow use of BPQCODE 
version 4.04 with the HexiPus™ 
once again. 


John, G8BPQ, sent his apologies 
for overlooking adding this change 
to the recent BPQCODE documen- 
tation. 


—Herb Salls, WB1DSW 


Bug! MF J's in Node 
Operation 


Copied from Quarterly aug 91 

MFJ TNCs wired incorrectly may 
be causing massive slow-ups in multi- 
port nodes. A miss-documented pin 
on the 25 pin connector could be 
causing collisions on the matrix of 
nodes with more than two TNCs. 
The Octopus, HexiPus™ documents 
(and MFJ man-ual) describe pin 20 
as the RTS line when actually pin 4 
is the RTS line. This causes some 
TNCs to not know that another TNC 
is already talking on the Matrix. 
The fix is to simply jumper pin 4 and 
20 on all MFJ TNCs' DB25. Also do 
the Wink-N-Blink mod described in 
the Annual. 


—Tadd Torborg, KAZDEW 


MSYS To NEDA Hexipus™ Interface 


Copied from Quarterly feb 92 

This information is for those who 
wish to connect a computer directly 
from a serial port into a TJP Octo- 
pus or a NEDA Hexipus diode ma- 
trix. This computer could be running 
MSYS BBS/node software, for ex- 
ample. 


There was an article in the Spring 
1991 issue of the NEDA Quarterly 
that allows you to do this with a 
computer running G8BPQ network 
software into a matrix. That scheme 
does not work with MSYS. This in- 
formation does work and has been in 
service at KA2JXI BBS for more than 
3 weeks without a hitch. 


This mod is performed on your 
computer serial card, and involves 
adding two 10,000 ohm, 1/4 or 1/8 
watt resistors. 


For use with a serial port using 
a DB-9 connector 

Locate pin 2 on the DB-9. Trace 
this back to a pin on it’s 1489 line 
receiver integrated circuit (could be 
pin 1, 4, 10 or 12). Solder a 10K 
resiator from this pin to a grounud 
trace on the PC board (could use pin 
7 of the 1489). Next, locate pin 8 on 
the DB-9 and trace it back to it’s 1489 
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line receiver IC (could be pin 1, 4, 10 
or 12). Solder another 10K resistor 
from this pin to a +12 volt source, 
such as pin 14 of a nearby 1488 line 
transmitter IC. This completes the 
mod to the serial board for a DB-9 
connector. 


For use with a serial port using 
a DB-25 connector 

Locate pin 3 on the DB-25. Trace 
this back to a pin on it’s 1489 line 
receiver integrated circuit (could be 
pin 1,4, 10 or 12). Solder al10K re- 
sistor from this pin to a grounded 
trace on the PC board (could use pin 
7 of the 1489). Next, locate pin 5 on 
the DB-25 and trace it back to it’s 
1489 line receiver IC (could be pin 1, 
4, 10 or 12). Solder another 10K 
resistor from this IC pin to a +12 volt 
source, such as pin 14 or a nearby 
1488 line transmitter IC. This 
completes the mod to the serial board 
for a DB-25 connector. 


Note that these modifications do 
not affect the serial port for use in 
other applications, so the mod may 
be done and forgotten. They do not 
have to be removed. 
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Connecting the modified 
computer port to the diode 
matrix: 

Serial port with DB-9 connector: 


Serial TJP Octopus Hexipus 
Pin 1 Connect to pin 4 & 6 

Pin 2 TXD pin 3 

Pin 3 RXD pin2 

Pin 4 See above 

Pin 5 SG pin 5 

Pin 6 See above 

Pin7 DTR pin 8 

Pin 8 CTS pin 7 
Serial port with DB-25 connector: 
Serial TJP Octopus Hexipus 
Pin 2 RXD pin 2 

Pin 3 TXD pin 3 

Pin 4 CTS pin 7 

Pin 5 DTR pin 8 

Pin 6 Connect to pin 8 & 20 

Pin 7 SG pin 5 


Pin8&20 Seeabove 


NOTE: Some serial ports actually 
control the computer serial port DTR 
line in such a manner that it is 
switched to NOT TRUE state when the 
port sends data. If this is case with 
your’s, and it interferes with the 
computer’s ability to send data to the 
matrix, you may have to cut the PC 
board trace to the DB connector’s DTR 
pin and connect a 1,000 ohm resistor 
from the connector end of the cut trace 
to a +12 volt source (such as a 1488 IC 
pin 14). 

—Roger, KA2JXI @ KA2JXI.ny 
—bbs sysop, Potsdam NY (OGDENB node) 
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Kantronics D4-10 UHF Radio Digital Repeater 


Copied from Quarterly feb 92 

[Here's some followup information on 
the digital repeater project that was 
reported on in the last NEDA Quar- 
terly using the Kantronics D4-10. - 
Ed] 

We now have a 19.2KB full duplex 
digital repeater on the air here in 
Dayton. It’s built from two 
Kantronics D4-10 DataRadios wired 
back-to-back with minimal glue and 
control circuitry. 


The frequencies are 420.950 input 
and 430.950 output. The antenna is 
an 11.5db gain Diamond Omni 
(specially cut for 430MHz; they <are> 
available if you whine enough). 
Were using a 4-can TX/RX duplexer. 


The design is really simple... es- 
sentially, RXD from the receive ra- 
dio is passed to TXD of the trans- 
mitter and DCD is passed to PTT. 
The minimal glue is a single 4049 hex 
inverter. Of course, interfacing to a 
TNC to tie the repeater to a node, and 
the control stuff to keep it legal, adds 
some complexity, but not much. 


A few things we’ve learned: 

1) The UHF band is not an ideal 
home for even moderately wide band 
packet. Our first channel choice — 
420.75/430.75 — was scotched be- 
cause it turned out the local ATV 
repeater had its audio output on 
430.75. Then, it turned out that a 
local repeater had audio links every 
100KHz from 420.075 to 420.975. 


These problems were solved by 
moving to 420.95in/430.95 out, and 
working a deal with the repeater 
group to free up the 420.5-430.0 
range. 


Now, were still hearing some sort 
of link (or possibly a spur) on 430.95 
occasionally. We're pretty sure we'll 
be able to either move it or live with 
it, though. 


But ATV is the real bugger in this 
range. Assuming the common 426.75 
video carrier frequency, operation 
from 430.05-430.55 is likely to cause 
some interference to the ATVers, 
though not much to our operations. 
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Above 430.55 is probably OK, but 
audio on 430.75 may screw up that 
channel (as it does for us). 


Since the 425-431 ATV channel is 
pretty universally accepted, and the 
430-431 range is also allocated for 
wide-band packet in many areas (at 
least in theory), the potential for 
trouble is great. Repeaters and links 
aren’t allowed from 431 to 433, 
there’s weak-signal and satellite stuff 
above that, and there’s likely to be 
another ATV channel (in our area, 
the repeater input) from 437-442. 


Anyway, be prepared to do some 
dancing if you plan to use a bunch 
of 100KHz channels on UHF... 


2) The repeater runs with no 
squelch tail. In our case, this was 
necessary because we're using 
squelch for DCD (refer to my earlier 
postings for endless ramblings on this 
subject). It works pretty well, though, 
even through the repeater we're 
using TXD of 20ms with good results. 


3) Since we’re not regenerating 
clock at the repeater, the system will 
actually pass any data speed up to 
19.2 (or beyond?) that deviates +/- 
10KHz from center. That makes 
things interesting for experiment- 
ers... 


4) The wider (60KHz) bandwidth 
of the 19.2 signal has its effect; a path 
that’s solid on 2M packet with omni 
antennas doesn’t cut it on 430 even 
with a 22 element beam at one end 
and an 11.5db omniat the other. Id 
be a lot more comfortable with radios 
that ran 25-30 watts than 10-12, but 
one takes what one can get... 

(Note, though, that on a good path, 
30-40 miles is no sweat with these 
radios.) 

Anyway, we’re having fun (I 
think...) 


John Ackermann, AG9V 
Miami Valley FM Association, Dayton, 
Ohio. 


| 430 
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Hardline Connector Help 


Copied from Quarterly feb 92 

While shopping around last fall 
at the ELMIRA hamfest, I met 
Walter Obenhofer, NQ20 who was 
selling various types of hardline 
connectors. I believe that Walter 
machines these items himself, and 
a beautiful job he does! The con- 
nectors he machines in his hobby 
time look and work just as well as 
commercially produced connectors 
costing up to two or three times as 
much. 


I decided to give it a shot and 
purchased several of his “economy” 
cable connectors and installed them. 
The connectors, which came complete 
with O rings to keep moisture out, 
worked great. Walter also provides 
excellent service on telephone orders. 
I had to order some additional con- 
nectors to finish a project on my new 
tower, and the special 7/8" N fittings 
were delivered very promptly. Even 
when [had to “special order” a fitting 
for solid core cable, Walter was able 
to provide this part and he even sent 
extra center pins for my convenience. 


Hats off to NQ20 for his fine ser- 
vice to the amateur community. 
Should anyone need any type of 
hardline connector, give him a call. 
Walter either stocks or can create 
connectors for just about any type of 
feedline you might have at very 
reasonable prices! His address and 
phone number are: 


Walter Obenhofer NQ2O 

159 Lighthouse Road 

Hilton, NY 14468 

Phone 716 392-4231 after 6:00 pm 
—Bob WB2QBQ 


OE ————————————— 
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Modifying the Motorola Mocom 35 For 9600 Baud Packet 


copied from a Great Lakes 
International Digital Association 
technical bulletin as published in 
Quarterly feb 92 

## NOTE.. Start with a operational 
tuned up radio on the frequency you 
are going to be using it on. 


1 Remove DC power cord, An- 
tenna cable, and take the radio 
out of the case. 


2  Fromthecomponent side of the 
radio, remove jumper from pin 
#40 and #41 located with the 
front of the radio facing you just 
to the left of the center partition, 
about an inch and a half from 
the back. NOTE.. keep this 
jumper. 

3 Remove the ends from the 
jumper in previous step. Obtain 
a 1.1 uH RFC and place insu- 
lating covers on leads, (note do 
not cut the leads on the rfc use 
full length), solder the jumper 
ends to the ends of the RFC. 


4 Install this RFC on Pins #40 
- and #3, note #3 is located to the 
right of T101 and the left of 
Variable resistor. on the left side 

of the radio. 


5 Remove capacitor C119 to the 
right of T102. 


6 Remove capacitor C117 to the 
right of T101. 


7  Turnradio over front facing you 
solder side up. 


8 On the right hand side locate 
T101 and T102 near the rear of 
the chassis. 


9 Cut trace to the right of T101 
alignment hole, between the 
first and second componet holes 
on trace going from front to back 
of set, (this trace has three com- 
ponent holes) see figure 1. 

Add a 4 inch length of hookup wire 

here on top side of board to xtal 


Add a 47pf mica from point A to 
ground. Add a 36 pf mica from point 
B to ground. 


10 Solder a 47 pf Mica capacitor 
from hole A of foil you cut in step 
9, to ground. See figure 1. 
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Nig x 
& T101 


A 
Figure # 1 


11 Solder a 36 pf Mica capacitor 
from hole B of foil you cut in step 
9, to ground. See figure 1. 


12 See Figure 2 and cut trace to 
front right of T102 between 
point A and middle hole of trace. 


T102 
alignment hole -> (0 ) 


ms to 


36pf 
here to a 
ground Trace 
Here 


Figure 2 


13 Connect power cord, antenna 
and turn on and retune T101 
and T102 before continuing 
with modification, once tuned 
remove power cord and an- 
tenna. 


14 Locate the Transmit Crystal 
channel element and remove 
from board. 

Open up the element and remove 
the fixed capicitor approximately 25 
to 32 pf that is in parrallel with the 
varialble capacitor. Solder a 4 inch 
lenght of small hookup wire to the 
junction of the variable capacitor, 
crystal and thermisistor, on the foil 
side of this pc board. re-install the 
crystal circuit in the plastic element 
case and file a notch on the side of 
the plastic case for the jumper wire 
to exit between the plastic cover and 
the main chassis when reinstalled. 
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15 Reinstall the channel element 
on the main chassis. Solder the 
jumper wire from the crystal el- 
ement to the rear hole where 
C117 was removed next to 
T101, (see figure 1). This is the 
is the junction of CR102 and 
R112. 


16 Locate the mic jack on the left 
side of the chassis component 
side front facing you. There is 
a 10 pin terminal strip running 
along the left side rail, number 
these terminals from front to 
back (1 to 10). 


17 Disconnect the wire running 
from the mic connector to ter- 
minal strip pin 5. Solder this 
wire to blank terminal pin 7 on 
this strip. 


18 Using a length of RG174 or 
teflon equiv. coax, prepare one 
end, and solder the center con- 
ductor to pin 7 of terminal strip 
on left side. Solder the shield to 
terminal 9 of same strip. 


19 Feed this coax between the face 
plate and the pcboard near the 
speaker from the top to the bot- 
tom of the chassis. 


Turn the radio over with the 
face toward you and the solder 
side up. 
Locate the metal shield in the 
shape of a trapizoid, near the front 
right side of the pc board (this shield 
has a 3/8 inch hole in itfor alignment 
of the Discriminator). 


Along the front left angle side of 
this shield is a jumper wire con- 
necting the shield to the pcboard. 
Just to the rear along this side the 
very next foil trace is the discrimi- 
nator output. There is possibly a 
printed triangle with the number 15 
pointing at this foil pattern. This is 
the junction of CR2, R35, C48, R37, 
R38. 


Using the Free end of the RG174 
you just installed in step 18, measrue 
and cut to length and prepare the end 
so that it can be soldered to the above 
described discriminator trace. 


20 


N.A.P.R.A. Notebook v1.0 
© NAPRA 1992 


Solder the center conductor to the 
trace described above and solder the 
shield of the cable to the metal shield. 


21 Connect the DC power cable 
and antenna to the radio, align 
the transmit crystal to fre- 


quency. 
22 Pin pinout of terminal strip on 
top left hand side is: 
front 
Pinte LL 
pin 2.... Transmit audio 
pin 3....ground 
pin 4....ground 
pin 5....wire from speaker 
pin 6....unknown 
pin 7....new discriminator output 


pin to mic connector 
pin 8....jumpered to pin 10 
pin 9....ground 
pin 10..+12 volt DC input to radio 


23 Microphone connector 6 pin Din 


plug 

pin 1....rx discriminator audio out- 
put to tnc 

pin 2....ground 

pin 3....ground 

pin 4....9600 baud tne audio input 
to radio 

pin 5....PTT line 


Tne, set the tx audio level in the 
9600 baud modem as per instructions 
from PacComm, and your away to 
Happy Packeting. 


I hope that this Bulletin is of some 
help to other’s working on System 
development, more in this series will 
follow as modifications are made. 
Next will be a writeup on the Mocom 
70 series conversion which is very 
simple because it is true FM to begin 
with, Also the Motorola Moxy, and 
the Motorola Maxar will be modified, 
these are also true FM. 

—Ron, VE3MX 


—sysop of Port Colborne Ontario node 
—asst sysop VESSNP BBS 
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Students Participate in Amateur Packet 


Copied from MAPRA Digitell, as 
printed in Quarterly feb 92 


NEW HAMPSHIRE EDUCATION 
BULLETIN # 4 DE WB1GXM ASSISTANT 
SECTION MANAGER NEW HAMPSHIRE- 
EDUCATION G.E.A.R.S. WEATHER 
PROJECT 

Increasingly, more school groups, 
licensed educators, and students, are 
using Packet Radio. School traffic 
between schools across town and 
across the world can be seen daily 
moving from node to node or via 
Aplink. Much of it is packet pen pal 
traffic, school contacts, and teacher 
to teacher contacts. 


The nature of this traffic is start- 
ing to change. KBOCUS, Chuck 


Bryant, Marlbourogh Elementary . 


School, Kansas City, Missouri, uses 
this medium for the collection of 
material for his student newspaper, 
Bacon Bits. Recently, he was the 
national collection point and Packet/ 
landline interface for Geo Quiz, a 
geography game involving over 29 
schools across the nation. 


Closer to home, the Goshen- 
Lempster Educational Amateur 
Radio Society, or G.E.A.R.S. has been 
using packet as a way of collecting 
weather data from individual sta- 
tions and schools for a science unit 
on weather. It will be used for 
graphing and comparing both in 
science and math. 
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Both licensed and unlicensed kids 
participated in intergrating Amateur 
Radio into the science project, 
showing what Amateur Radio can do, 
and motivating other students in 
becoming licensed. 


The project was initiated with an 
announcment at a meeting of the Mt. 
Ascutney Packet Radio Association 
(MAPRA) and by sending a packet 
bulletin addressed to NEBBS. 


The GEARS is using an Advanced 
Electronic Applications PK-88 ter- 
minal node controller, with AEA’s 
latest firmware, at the school in 
Lempster, NH, WB1GXM-4 Mbx, 
and in Claremont,NH, WB1GXM-1 
Mbx. By using two tncs, stations in 
and out of the area were able to auto 
forward via WA1LYTW.NH.USA.NA 
to WB1GXM-1. 


The kids, with an assist from me, 
download the data at classtime. This 
was their first exposure to 
telecomputing and Amateur Radio. 
Several are now in GEARS’s fifth 
Novice class. 


Looking into the future, the con- 
tinued technological advancement of 
Packet can assist other school 
telecomputing projects. If you have 
an idea for using packet, please 
contact me at the address above. The 
kids and I would like to hear from 
you. 


—Conrad WB1GXM 


Page 131 


ROSE X.25 Packet Switch Development 


Copied from NEDA Quarterly June 92 
The following is a development history of ROSE that | had asked 
Andy to compile for Quarterly readers some time ago. Andy 
graciously complied and so now we have a better view of this 
alternate packet networking method. It is my hope that by ex- 
ploring the similarities and operating environments here in print. 
that some will be encouraged to experiment with both ROSE 
and ROSE-TheNET interoperability. As Experimenters hams 
should leave no stone unturned! 
-NEDA editor 

Contrary to pronouncements to the contrary, Tom 
Moulton, W2VY, continues to actively develop the ROSE 
X.25 Packet Switch. Users of the RATS ROSE Network 
can attest to this — Tom uses our network to test new 
code! 


ROSE Switch version history, and future plans, is in- 
cluded as a “read.me” file in the ROSE distribution ZIP 
file. That file, taken from ROSE X.25 Packet Switch 
Version 2.9 (release date 920501) follows. 


28 June 1990 

Switch was not setting a couple of Reserved bits in 
the numeric digi field, this was causing one vendor’s code 
to crash. Had a bug where the T3 (Check) timer was 
not being started if the user was running AX25L2V2 OFF 
(if Ver 1). 


Note that L2T2 and L3T2 should be set to 4 if users 
are using 256 byte frames. If they are using 128 byte 
frames then the defaults should be OK. 


The switch will now allow calls on LCN’s that are out 
of range. What this means is now when connecting to 
an unconfigured switch the MaxVC 5 is no longer needed. 
It will not allow more than 5 connections until it is con- 
figured and the link is brought down. (Most easily done 
with the power switch or by using BOOTER.LOD) 


2K KKK KK Major Bug Fixed 2 2k 2 2K 2K OK 

There was a bug from since before 060289 where when 
Switch A was connecting to Switch B and Switch B did 
not know about Switch A when the Level 3 was Restarted 
it might crash based on what was in high RAM. This 
would also vary from machine model (if TNC2 vs PK88 
or DR-200, etc) which explains some other oddities that 
have been seen. 


Independence Day 1990 

Fixed a bug that would add garbage entries in the us- 
ers display if a user tried to connect through two (or more) 
digi’s using the switch as the first. (Did not specify a net- 
work address) I don’t think this would really cause any 
problems but it might have, since the USER Linked to 
had a pointer that was pointing off into memory some- 
where - but i don’t think it would ever modify anything 
out there... 
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13 July 1990 

Have invalid connect requests (except to self) be ig- 
nored instead of returning a DM (if *** BUSY). Allow 
for L in X.121 Address to be translated to the digit 1. 
(Should have been this all along, I did have a typing class 
once!) 


Repaired the PK87/88 overlay. Renamed it to be 
PK88.OVR. 


All references to PK87 should be changed to PK88! 


10/26/90 


The 900713 version has been performing very well. 
This version only has three changes. 


1) Password protection to LOADER 


2) The RS232 port now supports the diode matrix used 
for Net/ROM as well as standard RS-232. 


3) Clean up for CONFIG and LOADER and fixed a 
bug in USERS. Config and Loader would not properly 
handle the case of someone attempting to connect to them 
while someone else was using them. And Users would 
not allow more than one connection at a time (fixed). 


Added two new applications: MHEARD.LOD gives 
a shorter heard list when it is loaded, users still connect 
to HEARD. INFOSP.LOD has Spanish messages on the 
disconnects. 


If using an RS-232 LAN you need to cut the jumper 
between 10 and 20! 


**** SEE MANUAL.UPD for changes to the manua!!!!! 


11/11/90 

The EPROM defaults to having No Password, can be 
changed via CONFIG. Added some space after the COPY- 
RIGHT NOTICE for local LAN info. 60 Bytes (My copy- 
right message is “ROSE X.25 Packet Switch Version 
xxxxxx by Thomas A. Moulton, W2VY” ) 


To make the text get sent to users you will need to 
modify two pointers, these are 12wdta and |2eob, see 
ROSEZSW.LST. Note that l2eob points to the Last char 
of the string and 12wdta points to the next location. (Gf 
12wdta = 12eob+1, Always!) 


The password can be burned in EPROM as well, lo- 
cation defpwd. The first byte to the number of charac- 
ters the reply needs to be, the second byte is the length 
of the key (40 max) and the next 40 bytes are the key. 


Both of these will be modifiable via CONFIGUR.EXE 
in the near future, and I will send a message to 
ALL@ROSE when it is ready for download. 
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8/10/91 

One major change - All Messages out of the switch 
that BBS’s or other programs might look at now start 
with “Call.” Here is the list: 


Call Being setup Call Completed to 
*** Call Clearing *** 
*** Call Reset *** 


I did some space conservation. Also wrote an appli- 
cation (aka .LOD) that will print out the contents of the 
LINK (Level 2) data structures. This is really only useful 
to help debug the NO PEER problems. Do the follow- 
ing: Upload UDUMP.LOD (You may have to BOOT the 
switch first, it is BIG!) then when you have some NO 
PEER’s connect to UDUMP and hit return (With cap- 
ture file open) - It will print a lot of information. Send 
me the file either by mail, packet or MODEM (The lat- 
ter is preferred) 


30 Aug 1991 

Some space conservation, changed the memory usage 
limits to send RNR’s a little sooner (So there is more 
memory to work in) to help the RR/RNR loops. Also made 
a change upon when the timers are reset, to help avoid 
the RR/RNR loops. This is an attempt to avoid the prob- 
lems. 


Also made a change to application connect logic to allow 
a single application to accept connects for many desti- 
nations, This is to be able to start working on CONFER- 
ENCE Bridge and Broadcast Applications. 
10 Sep 91 

Added some debug code to detect where the NO PEER 
vce’s were cleared from within the code. 
25 Nov 91 

Added better flow control for VC’s and L2 Links. We 
hope that this will reduce/eliminate the NO PEER prob- 
lem. Will also reduce the amount of data taken by a single 
VC. 
30 Mar 92 


Moved, Son was born, bought new computer,... Up- 
dated Applications to not respond to CR and to send all 
data when you first connect to them (Like INFO). To 
keep various people happy am calling this version Version 
#2.8, many things will still be based upon the date. 


The file names will be changing to have the version 
number instead of date! 


The idea is to be able to say that we will have PID 
(aka TCP/IP) support in version 3.0 
Also now support updating TXDelay from CONFIG! 


:020E000000 Read the value and :010E0100ttcc TT 
is TXDelay value (HEX 10ths of milliseconds), CC is 
checksum 


28D8 is default if you increase TT by 1 decrease CC 
by 1 (28h = 40 is 400 MS) 
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Also removed MHEARD.LOD and modified 
SHEARD.LOD to only allow one Heard List per connec- 
tion. (Single-eHEARD). 


1 May 1992 Version 2.9 

Added new parameter to clear packets, the switch can 
now indicate where a clear originated. This means if you 
are told 0D00 you will also know Which Switch has the 
problem! The required many updated to the handling 
of call setup and clearing, so the information could be 
relayed back. It will only be displayed to the user when 
INFO.LOD is loaded, and will not be displayed when 
in Reliable mode. Also pass Q, D and M bits correctly. 
And found a bug is the passing of Call User Data. 


Future Releases: 
Version 3.0 

Full Support for Protocol ID’s (PIDs) Other than F0 
(User Data) — This means that TCP/IP and any other 
Protocol will be transported by ROSE Switches. Alpha 
testing will be in June and it should be released in July 
1992. 


Version 3.1 

Support for Packet Fragmentation. In earlier versions 
all links ran with a packet size of 256 and if a packet 
was ever broken up (on an HF link for example - 32 Bytes) 
it would not be re-assembled. This version will support 
this re- assembly. 


Version 3.2 
Support for reception of large frames (2K). They will 
be fragmented and sent through the network and re-sent 
as a single frame upon exiting the network. 
These changes should take us to the end of the year. 
Other items that will be worked upon in between these 
include: 


* Configuration of L2 and L3 parameters on a Link by 
Link basis * DOS Device Driver * Data Engine * 
Support for Tiny-2 Plus and Expanded Memory Board 


Thomas A. Moulton, W2VY 

W2VY@WB2GTX.nj 
100 Overlook Terrace Bloomfield, NJ 07003 (201) 338- 
W2VY 


—Andy Funk KB7UV 


RAT on the ball —> 


2400 Baud Applications: Effective Throughput Analysis 


Copied from NEDA Quarterly June 92 

When I first heard about the availability of 2400 baud 
modems for packet, I was very interested. Twice the 
speed, although not terrific, was still better and the 9600 
baud alternative required special radio characteristics 
and there was little knowledge about making 9600 baud 
work thru the available radios. The “thru the mic” in- 
terface that 2400 baud allows was at least a partial so- 
lution. 


Then over the next couple of days and conversations 
with several individuals, reality started to set in. It was 
not twice as fast. I realized that at 2400 baud an ac- 
knowledgment packet takes virtually the same time as 
at 1200 because of the radio key up times. Add to that 
the key-up time when starting to send the next burst 
of data packets and other bits of dead time and very 
quickly the increase in speed gets dissipated. Under op- 
timum conditions with short Tx delays and large frame 
sizes, a 50%+ increase in speed could be achieved, but 
more typically only a 30% increase in speed might be 
experienced. That is assuming there is no other activ- 
ity on the channel. If there is some other activity, or a 
simplex hop is used, the send\ack cycle gets lengthened 
and any speed benefits gets virtually lost. One of the 
few benefits that helps is that with shorter bursts the 
probably of getting hit by a hidden transmitter is reduced. 
All in all it did not appear that the cost of the 2400 baud 
modems was worth the performance increase. Although 
I did experiment, I like many other of the system op- 
erators had pretty much written off 2400 baud. 


Over the past couple of months, I detected a flaw in 
my logic. The flaw is that I had assumed that as chan- 
nel congestion increased, the speed advantage would be 
further diluted. This is not entirely true however. 


I find that prevailing operation conditions differ now 
from the past when I had made come to my original con- 
clusion about 2400 baud. With many sites now being 
backboned to servers and simplex hops much less com- 
mon, while at the same time other users on the chan- 
nel at the same time are more common. Typically what 
may be experienced when working a server directly or 
a server thru a node is burst of data separated by sig- 
nificant pauses. This is due to activity causing delays 
while the server or node waits for the channel to clear 
to send more data. Sometimes it is because of several 
users of the same port and air time gets divided between 
the users. A typical user may see a 2 second burst of 
data every 15 seconds or so. This can put the average 
throughput down around 200 baud. Under these cir- 
cumstances a 1200 baud HTS free link has no trouble 
supplying data to a user port. 


In my logic, I only made comparisons between what 
1200 baud can do on a clear channel compared to 2400 
under the same. I did not consider busy channels like 
the above. When the channel is busy the send/ACK turn- 
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around times become insignificant compared to the time 
waiting for other data to pass. As mentioned above, at 
1200 baud a 2 second burst of data with a 10 second pause 
will result in a average throughput down around 200 
baud. At 2400 baud with the same TNC parameters, 
the user may see a 1 second (same amount of data sent 
in half the time) burst with still 10 second pause (since 
other users may still be using 1200 baud). This results 
in only a increase to an average of 218 baud from 200 
baud. Again a minimal increase and my logic appears 
to hold. 


In my earlier logic, I did look at the effects of increasing 
frame size and number of frames sent in one burst and 
found that the send/ACK turn around time still signifi- 
cantly cut into speed improvements at 2400 baud. Now 
lets assume that on our busy channel, we configure the 
station running 2400 baud to send twice as much data 
in one burst (i.e. maintaining the same length burst). 
Then at 2400 baud 2 seconds of data are received with 
a 10 second pause which yields an average of 400 baud. 
There it is 400 baud instead of 200 baud! It is truly twice 
the throughput that a station running 1200 baud would 
see. The reason we now experience this increase is that 
the send/ACK turnaround time is no longer a factor. 


Now lets assume we set up a dual 1200/2400 baud 
userport. Users then would be able to upgrade their 
TNCs and see this performance gain. It also should be 
noted that there has not been significant advancement 
in basic TNC2 hardware for a long time and that many 
of the users may be willing to make the $60 to $70 up- 
grade since it has been years since they purchased their 
TNC. If we further assume that a significant number 
of the users make an upgrade to 2400 baud, that 2 sec- 
onds of data with a 10 second pause may change to a 2 
seconds of data with a 7 second pause because another 
station using the channel that you would be waiting for, 
could now be running 2400 baud reducing the delay time 
between data bursts. This further increases the aver- 
age throughput to 533 baud which is more than 2.5 times 
as fast as things were when everyone was on 1200 baud. 
Who would have guessed that a 2:1 increase in data rate 
in fact increase average throughput greater then 2:1. I 
am not pulling your leg. Keep in mind that I am talk- 
ing about average throughputs that are down around 
one quarter of the actual data rate because of conges- 
tion. 


Through the above logic, I have concluded that it is 
worth investing in 2400 baud userports where the pre- 
vailing conditions are as I described. Whenever expe- 
rienced average throughput is one third or less of the 
maximum obtainable average throughput, 2400 baud 
properly configured will provide a 2:1 increase. If enough 
stations operate at 2400 baud greater then 2:1 can be 
experienced. A special 2400 baud only LAN would pro- 
vide even better performance to those stations that up- 
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grade. However it should be noted that operation on a 
uncongested channel at 1200 baud will perform nearly 
as good as 2400 baud under the same conditions. There 
are some other issues that should also be considered such 
as what about all those TNCs with open squelch DCD 
capability that may be on the channel you are trying to 
operate 2400 baud? It is true they will not detect the 
2400 baud. I submit it is not as big a problem as you 


may think. The additional collisions relative to the hid- 
den transmitter problems already experienced on most 
user LANs will be minimal. That is another long dis- 
cussion to which I will not go into here. For a dual 1200/ 
2400 baud userport I recommend a open squelch detec- 
tion circuit which detects both 1200 and 2400 baud rather 
than squelched operation. This is not difficult to imple- 
ment, I'll try to get together something for the next Quar- 
terly. 


—Bill NX2P 


Making K9NG Modem Work With More Radios 


Copied from Quarterly feb 92 
The following mods should be useful in making the 
k9ng work better with more radios: 


Data-derived RX Clock may be derived from U4 pin 9. 


Half an LS02 can be used to buffer and gate RXD and 
RXC with DCD/, which will really cut down on the 
number of frame aborts in the switch or TNC. 


R31 should be changed to 0 ohms, and C18 should be 
increased to .1 uF to improve the DCD circuit. Cuts 
down on chattering. 


If you don’t have a 16x or 32x clock available, a4060 and 
a 4.9152MHz crystal will get you one for about $3 total. 


At 4800 bps, no changes are needed to the input RCV 
Filter, but at 9600 bps, the capacitor values are quite 
critical because the low-pass filter cutoff is too close to 
4800 Hz. If your radio has a decent IF, you can just cut 
the values down and you'll get fewer damaged received 
packets. (In fact, what I do is reduce C13/14 from a 
parallel combination of 2700 and 1800 pfto just the 2700 
pf, and use the single 1800 pf left over instead of C15/16, 
which used to be 2200pf + 56pf.) 


Change C19, a 220uF capacitor, to something like 6uF 
to avoid frying the regulator. 


For a TNC-2, jumper the modem header pin 3 to pin 4 so 
that THENET can find itself. Don’t cut the jumper on 9- 
10, sothat the keying circuit inside the TNC will continue 
to work. Do cut the jumper on 7-8. Putting a jumper 
across 1-2 will let the DCD light on the TNC work. 


Hanging a diode from U2 pin 6 to the RTS/ line (solder 
it from the right-hand side of R26 to the right-hand side 
of D3) will inhibit the DCD/ output while you’re 
transmitting, which might confuse things. 


Note that because of the hang time of the DCD circuit, 
you WILL get a brief burst of DCD after you unkey, but 
that’s unlikely to cause any problems even in a critical 
device driver, since you will have already told the interface 
to deassert RTS/, and presumably youre therefore ready 
for incoming carriers. 


Oh, and of course you can leave out all the stuff after U6 
pin 10 and U2 pin 14. That’s all just DC switching stuff 
that you won’t need if you’re using the TNC’s PTT or 
some external PTT. Ifyou are using the modem without 
a TNC, you can use U6 pin 10 to drive a transistor, or a 
555 and a transistor if you need a blab-off. 


RTS/ is not asserted. 
—Brian Kantor wb6cyt 


Radios Suitable for 9600 Baud Packet Use 


Copied from Quarterly feb 92 

Motorola MAXAR and MITREK have both been modi- 
fied for 9600 by Brian wh6cyt, for the k9ng; these will 
work with the g3ruh as well. 


There are some 9600 baud ready radios, like the TEKK 
KS-900, Kantronics DVR 2-2 (not recommended), and 
D4-10, but most of us will be using our existing radios 
for 9600 baud packet. Here are some specific “mods” 
and tips. 


From James Miller g3ruh: 


Radios known to be used at 9600: Alinco: DR-1200 
DataRadio, ALR-72, ALR 709; Kantronics DVR 2-2 Data 
Radio; Icom IC:22, 25, 38, 228, 271, 290, 471; Kenwood 
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TR: 7500, 7700; TM: 211, 212, 221, 231,431, TS: 700 and 
770; Standard C58, C140; Yaesu FT series: 212, 221, 
230; (We may assume that this is with the g3ruh mo- 
dem) 


Icom IC290H/V: RXA may be obtained at IC12, pin 
9, on the main board; TXA may be injected at D-3 cathode 
on the main board, through a 680 ohm resistor. This one 
is my personal 2 meter 9600 rig, and works great with 
either modem. 


This material was passed on to me by WAZZKD who copied it 
from a note sent out by Mike Curtis, WD6EHR who had pro- 
vided the info in one of his postings to a 9600 Baud discussion 
group on Internet -Ed 
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Converting the ICOM IC-471A for 9600 Baud Operation 


Copied from Quarterly June 1992 
Don Lemke, WB9MJN 
24 March, 1992 

This document details the modifications neccassary 
to operate 9600 baud .5GFSK data modulation thru an 
Icom IC-471a transciever. This is the modulation that 
was originally developed for Ham Radio usage by Steve 
Goode, K9NG, and also employed in the G3RUH and 
TEXNET modems. 


Modulator 

The IC-471a has a “Direct FM” Modulator. This modu- 
lator uses a varactor, D4 on the “MAIN” C.B. (Circuit 
Board). This modification patches the 9600 baud FSK 
Transmit Audio into the modulator circuit, in a way that 
transmit audio, and the FSK audio have minimal dis- 
tortion. As with any 9600 baud modification to a “Di- 
rect FM” modulator, readjustment of the audio 
deviatation is recommended, after the modification. 


Step 1: Replace C17 with a .47 uF, 25 w.v. non-polarized 
capacitor. Thecapacitor should be physically appropriate 
in size. I use one that had a .3 inch lead spacing, was 
about .4 inch square, and one eighth of an inch thick. 


Step 2: Attach on the bottom of the C.B., a 3.3 KOhm, 1/ 
4 watt resistor to a C.B. trace between R30 and C17. 
Leave the far end free. 


Step 3: Attach a .001 uF, 50 w.v. disc ceramic capacitor 
to aground C.B. trace near the free end of the 3.3 KOhm 
resistor. Twist the free end of the resistor and this 
capacitor together. 


Step 4: Attach a piece of small coax to ground, and the 
junction of the resistor and capacitor. I used RG-178 
coax. The center conductor gets attached to the 
components. Insulate the connections with Fiberglas 
tape, so that when theC.B. is reinstalled the connections 
will not short out against the chassis, or the C.B. 


Step 5: Solder the other end of the coax to MOLEX socket 
terminals (#02-06-1103). Insert the center conductor 
terminal into the “Auxiliary” connector position number 
9, and the ground into “Auxiliary” connector position 
number 17. This completes the Modulator modification. 


TX/RX Turnaround Time Improvement 

The stock IC-471a applies power to its TX’er audio 
stages only during transmit. Thus, when the transmitter 
comes on, RC time constants in these circuits cause the 
transmitter to drift for approximately 1 second. To cure 
this problem, this modification reroutes the DC power 
for Q1 to a filtered +8V point, and enables the IC1 stages 
continuously. This modification is to the IC-471a “MAIN” 
C.B.. 


Step 1: Cut free the long lead of R26, which should be 
towards D3. 


Step 2: Solder a piece of jumper wire onto the free lead 
of R26, and insulate connection with heat shrink tubing. 
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Step 3: Solder the far side of the jumper wire to IC1, pin 
8. 


Step 4: Solder another piece of Jumper wire to IC1, pin 
8 and far end of this wire to the junction of D1 and R4. 
This completes the TX/RX Turnaround Time 
Improvement modification. 


Receiver FSK Audio 


The IC-471a uses a MC3357P Receiver IF chip. The 
discriminator output of this chip has a low enough im- 
pedance that it can directly drive a shielded wire with- 
out the signal being distorted. In addition, this audio 
signal is provided an unused C.B. header, J14 on the 
“MAIN” C.B. which is easily used to connect the sig- 
nal to the rear panel “Auxiliary” connector. 


Step 1: Obtain a.1linch spacing, 2 position, socket which 
will fit onto J14 and solder subminuature coax to the 
socket, so that the center conductor socket will mate 
with the J14 pin on the “R214” side of J14. The ground 
lead is soldered to the other position of the socket. The 
MOLEX catalog shows apart number 22-01-2026 for the 
connector housing, and it requires 2 type 4809c terminal 
inserts. 


Step 2: Solder a MOLEX socket terminal (#02-06-1103) 
onto the other end of the coax, ground lead. 


Step 3: Solder a .47 uF, 25 w.v. capacitor to another 
MOLEX socket terminal. Connect the coax center 
conductor to the other lead of the .47 uF capacitor, and 
insulate this connection with heat shrink tubing. 


Step 4: Insert the coax ground conductor terminal into 
the “Auxiliary” connector pin 15, and the capacitor 
terminal into pin 11. 


This completes the yeceiver FSK audio modification. 
Bringing it all together: The MOLEX part number for 
the “Auxiliary” connector mate is 03-06-2241, and the 
pin terminal part number is 02-06-2103. The connec- 
tor has 24 pin terminal positions, so if you plan on us- 
ing all these positions someday, order 24 of the 02-06- 
2103 part number. 


Comments on filters 

The IC471a has the ideal Receiver IF BW for 9600 
baud operation. As part of this project I measured the 
Receiver IF BW to be 14 KC at -6 dB. The 455 KC Fil- 
ter part number spec is 15 KC BW at -6 dB. The IC471a 
also has a crystal filter for the transmitted signal. On 
the RF.YGR C.B., FL2, a part number 70M15A, is part 
of the transmitter. The part number indicates the fil- 
ter is 15 KC wide at 6 dB down, I believe. The effect of 
this filter is to reduce the single bit transitions of the 
KONG modulation, by a small amount and time delay 
distort the signal a small amount. All I can report, is 
that this is not causing a big problem here on the ter- 
restrial 9600 baud LAN, where other users have TEKK 
and IC-475a radios. The IC-475a has this same filter- 
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ing. I am looking to replace this filter with a 20 or 25 
KC wide at 6 dB down filter. 


In a complete transmitter to reciever path, the sig- 
nal passes two time delay distorting filters, of the best 
BW for detection, for these type of filters. This de-opti- 
mizes things some. This report will be sent thru the IC- 
471a, 9600 baud station here, to the network, however. 
Illustrating that the effect is small. 


-IC-471a problems 

This IC-471a was used when I obtained it. Looking 
at the manual spec for receiver sensitivity, of .5 uV for 
20 dB Quieting, many of you might cringe. After look- 
ing at the receiver line up, and the parts used, this per- 
formance seemed somewhat odd. This is not a radio with 
a 6 stage helical resonator front end filter, and J-fet mixer! 
That type of radio would typically give the IC-471a’ speci- 
fied performance. The IC-471a is designed to have con- 
siderably better sensitivity than this, although obviously 
at the expense of front end overload handling. Some- 
thing is wrong. 


Measurement of my used IC-471a showed that besides 
the production and/or design problem I suspected, some- 
thing was really wrong with my particular radio. The 
sensitivity varied dramatically with temperature. It 
would start out on spec, then slowly get as bad as -90 
dBM for 20 dB quieting. This is BAD! 


I tracked the variable sensativity to a problem in the 
PLL box. As the unit warmed up, its output would vary 
from around .75 vrms to less than .1, on center band. I 
never “fixed” the PLL, but by removing the cover, and 
putting 1/4 inch spacers between the PLL enclosure and 
the module that is mounted over the PLL box, the PLL 
stabilized with enough output, that near spec sensitiv- 
ity was maintained. 


Next I went after the poor spec. While finger test- 
ing L29, the sensitivity improved, greatly. After replac- 
ing L29 with a new coil, with an additional turn (3 in- 
stead of 2), and the sensitivity improved about 20 dB. 


A 20 dB quieting signal needed less than -110 dBM, 
which is about .2 uV. This is the typical range for UHF 
receivers of this design! L29 is part of a PI circuit used 
to transform the PLL output impedance of 50 ohms to 
a very high voltage and impedance needed by the first 
receiver mixer stage, Q12. At this sensitivity, with a 
19 element F9FT Yagi, UO14 9600 baud was very easy 
to copy for most of the pass, even without a preamp. 


I include these experiences in this article on how to 
do 9600 baud packet, to hopefully make it clear to people 
that even a pretty looking radio can perform like gar- 
bage, and that if the radio isn’t working in the first place, 
the 9600 baud packet radio is not going to either. No- 
body should expect that they will be able to do 9600 baud 
Packet radio, with existing rigs, like they would do 9600 
baud telephone line communication. Yes, you may ac- 
tually need to learn and do some hardware electronics 
to do this. 


Concluding remarks: 

With these modifications, the IC-471a makes a nearly 
ideal 440 band 9600 baud packet radio. I’ve used mine 
on UO14, as a receiver, as well as over our 9600 baud 
terrestrial LAN. A PING test thru N4PCR-0/1, which 
uses a TEKK radio, and preamp, and one of the CELL- 
NET 56 KB, FDX radios described in the file 
CELLNET.UPT, to the K9VXW-1 node, where the other 
CELLNET prototype FDX radio is, passed 98 of 100 
kilobyte packets with the NOS Window = 2048, MSS = 
216. I hope this article is helpful, and will encourage 
some of you to take the plunge and try out 9600 baud 
packet radio. 


All commercial use of the information developed by 
the author in this article is reservered. Like somebody 
said, “I'm not making money at this, and I don’t want 
you to make money off me either”. In other words, you 
are free to do these modifications for yourself, or have 
somebody do them for you, if he or she gets nothing in 
return for it. 


—73, Don WB9MJN @ N9OHSL.il 


NEDA Makes Front Cover of CQ Magazine 


Copied from NEDA Quarterly June 92 

For those alert members who are readers of CQ maga- 
zine the June ’92 issue should have caught your eye. 
NEDA member Peter Brayman, KB2HPU is featured 
at the controls of his school’s club station twiddling the 
knobs of a Kenwood HF rig. Prominently visible on the 
desk in front of Pete are a set of NEDA Network Wide 
and Eastern NY Regional Maps. 


Pete, who is no novice to keyboarding about the net- 
work, frequently assists your Quarterly Editors in veri- 
fying node configurations for map updates. He also is 
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one of the remote sysops for the Oneonta Amateur Ra- 
dio Club’s MSYS BBS, W2RGI. OARC’s members are 
the primary support group for New York State’s Emer- 
gency Management Office in Oneonta, NY. The EOC 
in turn is used as the home location for the W2RGI BBS. 
Hats off to Paul Agoglia, WN2K who is the Unatego 
(NY) High School teacher responsible for getting the 
School Amateur Radio Club going, and to Pete Brayman, 
network hacker extraordinare, for the fine promotion job 
in their area! 
-Dana WA2WNI 
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Network Station Hardening - Preparing for the Worst of Times 


Copied from NEDA Quarterly June 92 

This is an article about how to “Harden” your packet 
station or network site for emergency applications. Site 
hardening is a term that comes from military specifi- 
cations for equipment intended to operate under very 
extreme conditions. While it is true that what we do is 
mostly hobby related, there is no reason why in some 
cases we cannot take reasonable measures to insure that 
our equipment does not become useless at the drop of 
a hat, or as in this month’s column, the drop of your lo- 
cal AC power line during a storm. Hopefully over time 
the Quarterly can cover some of the more common con- 
ventions for what is good engineering practice to pro- 
tect your station or node from various forms of hostile 
environment. For this month though I am only going 
to provide a simplified way to keep your equipment pow- 
ered up should your power source die or bite the dust. 


There are many forms of backup power systems, some 
are good, some are only mediocre when considering cost, 
ease of installation and overall effectiveness. The sys- 
tem shown in the diagram here is profoundly simple and 
I have been successfully using this configuration for a 
number of applications for at least 12 years. As you can 
see there are no switches, relays, sensors or other giz- 
mos to clutter up its effectiveness. The entire trick is 
done by isolating 2 power sources, one AC powered and 
one from a standby battery, using a simple set of blocking 
diodes. The battery should be of sufficient size and amp/ 
hour rating to run whatever equipment it is connected 
to for the amount of time you wish as an emergency 
operating period. Ideally this should be 24 to 48 hours 
of run time if your site is not easily accessible and is 
required for emergency use from time to time. More 
capacity is desirable, but not always feasible due to power/ 
cost restraints. The diodes should be whatever new or 
surplus monster diodes you can muster that will eas- 


AC Operated Primary 
Power Source: 13.6 VDC 


All equipment should have solid 
common See point. Use 
heavy copper braided ground wire 
between all separate equipment 
racks. 
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Backup Battery 


This page copied from the NEDA Quarterly v3.2, 
June 1992. NEDA is Box 563 Manchester NH 03105. 


ily handle the continuous loading of your equipment 
PLUS your battery bank if it is being recharged. The 
main AC power source should be capable of operating 
all your equipment at maximum load AND be able to 
recharge your battery bank thru charging resistor R1 
at the same time. The fuse is to protect the equipment 
from damage if anything goes wrong with your setup 
and allows obvious protection for the power supply and 
battery if the equipment is the thing to go west. The 
really neat thing about this setup is that you can make 
it as BIG or as little as you want, merely scaling the sizes 
and ratings of the components to match your applica- 
tion. My smallest application is a 12V 5 A/h cell on 1/ 
2 of a Radio Shack 2 amp bridge rectifier being fed by 
a 500 ma 13vdc wall transformer , bridged by a flash- 
light bulb for R1 and the whole array keeps a TINY 2 
alive for an EOC mini-BBS with a low power radio. The 
largest application so far uses 2 large stud 50 amp rec- 
tifiers and floats a set of 2, 12vdc 40 A/h wet cells. This 
setup uses an automotive headlight for R1 to limit re- 
turn current to the cells and the array feeds the main 
DC power buss to hold up all the radios on the back- 
bones of a major node site. In such setups it is impor- 
tant to set the float voltage getting to the cells at full 
charge such that the batteries are not being constantly 
overcharged. This can lead to dangerous outgassing in 
some cases, or overheating of the cells. It is important 
to take precautions in such cases to make sure that 
adequate ventilation is present and that the cells are 
not charged or floated at a rate beyond specs. 


If you wish it is possible to add all sorts of bells and 
remote whistles to this setup. For example, if you put 
a continuous duty relay on the AC source side of D1, and 
route all non-essential equipment power thru its con- 
tacts, then when the power goes out, all the non essen- 
tial equipment goes instantly off line, leaving the more 


Equipment 
(Load) 


= 
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essential stuff on line. When commercial power is re- 
stored, the powered down stuff comes back up. Simple 
yes? Remote control of TNC’s and peripheral hardware 
can also be achieved by using the LED ON / LED OFF 
feature of some TheNET code. By using a suitable switch- 
ing method a node manager can remotely control the 
power on equipment that might best be shut off when 
the node is needed for some emergency application. 


This is just a primer to get your brain in gear. Hard- 
ening a station is sometimes no more than doing some 
simple things to make it less susceptible to being inter- 
rupted. Power is just one of a number of things to take 
into consideration. Next time we will look into some 
simple steps to effective lightning /surge protection. 
Meanwhile, just make sure your AC powered supplies 
are plugged into readily available commercial surge pro- 
tectors. At a few bucks a piece it isn’t worth NOT hav- 
ing one in line with your gear! You may also be amazed 
to learn how cheaply you can DC ground your antenna 
systems! Remember that in the packet network, the total 
throughput effectiveness is only as good as the weak- 
est site. Don’t let the weak link when we need the net- 
work be yours! 


—DANA WA2WNI 
NEDA Emergency Services Advisory Committee 


SANA 


Was it 
protected? 


DOERS and the RAND Node 


Copied from NEDA Quarterly June 92 

Realizing the need to extend the NY State amateur 
packet backbone network to the north-eastern part of 
the state, the DOERS (Digital Operator’s Emergency Ra- 
dio Service) was established by KC2JO (John Taylor) 
and KD2AJ (Chuck Orem) in the fall of 1990. In De- 
cember of 1990 a coordination meeting was held in 
Plattsburgh to determine packet priorities and to dis- 
cuss with packet groups in the adjoining areas the best 
ways to serve the region and remain compatible with 
their needs. As a result of that meeting the DOERS be- 
came determined to not only complete the 4800 baud 
backbone north from the Saratoga region, but to also 
plan paths to Quebec to the north, Vermont to the east, 
Malone/Massena to the west, and Tupper Lake to the 
southwest. 


We are proud to announce that after a good deal of 
time, money, and hard work the 4800 baud link is com- 
plete to RAND:W2UXC-4 (on Rand hill, 8 miles north- 
west of Plattsburgh), and on to Alberg, Vermont 
(WA2SPL). 


RAND:W2UXC-4 was set up as a repeater node in or- 
der to deal with the hidden transmitter syndrome. The 
local userport, NYPLB:W2UXC-9, is on 144.91 MHz. 
Those connecting to RAND via the backbone (from the 
south for example) at present need to first C KT2M-1 
to get RAND on the nodes list. 


Special recognition should go to Carl Smith (N2JKG) 
DOERS President and our technical wizard, Burt Lang 
(VE2BMQ) site manager for the VE2RM site in Que- 
bec, Dick Jenkins (N2AYY) site manager for the 
WA2UM<X system, and Jim Mcknight (WA2UMxX) sys- 
op for WA2UMX BBS. 


In addition to the 4800 baud backbone link DOERS 
maintains the 145.01 PLB:W2UXC-1 node at Lyon Mt., 
NY and the 145.61 KD2AJ-1 Digi at Rand Hill. 


DOERS would be glad to share any additional infor- 
mation regarding the 4800 Baud Repeater. 
Send packet to: 
N2JKG @ KD2AJ.#4NNY.NY.USA.NA. 


—N2IXL - v.p. DOERS 


Baycom Software 


Copied from NEDA Quarterly June 92 

I have seen several bulletins over the past couple of 
months asking about Baycom version 1.50 software. Due 
to my commercial connections, I have not been able to 
answer these questions over the air. 


For you who have not heard, version 1.50a is now avail- 
able. One reason for the confusion is that this version 
unlike earlier versions is not shareware. Therefore it 
has not been available for download and was not an- 
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nounced “formally” thru packet channels. PacComm has 
contracted with Baycom to represent their interests in 
the United States. The new 1.50a version of the Bay- 
com software comes with a new printed manual and is 
available from PacComm, myself and other licensed 
agents. This software goes for $20.00 with the manual. 
PacComm also offers licensed Baycom hardware manu- 
factured here in the US. The total cost of a package for 
hardware and software starts around $65.00. 


-Bill NX2P 
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Interfacing PacComm NB-9600/G3RUH modem 
to Kantronics D4-10 


Copied from NEDA Quarterly June 92 

Due to numerous requests, I am posting modification 
instructions for the PacCcomm NB-9600 G3BRUH modem 
to convert it to TTL input/output to drive a Kantronics 
D4-10 at 19.2Kbaud. Don’t forget to change the radio 
speed jumpers in whatever TNC you are using to 19.2K 
after these mods are done. 


I mention this only because I spent one hour trying 
to figure out why my mod wouldn't work, only to finally 
realize I never changed the TNC speed to 19.2K to drive 
the blasted modem! (what an idiot huh?) It’s the simple 
things that getcha! :-) 

5 Feb. 92 


All part numbers given are for the PacComm NB-96 
modem. 


Receive audio in to receive data in (conversion 
to TTL input) mod. 

Locate U10 pin 2, and circuit board trace going to U5 
pin 2. 


1 Disconnect output of U10 pin 2 by either lifting the 
lead leg on the integrated circuit or by cutting trace. 
Lifting the leg on the IC is the easiest way to go 
about it. 


2 Connect TTL receive data input from the D4-10 to 
trace going to U5 pin 2. 

Note: On Kantronics 19K2/9K6 modem, they actually 
put in a jumper that lets you either drive U5 pin 2 
directly from a TTL source (such as the D4-10) or when 
the jumper is installed, the input to this stage reverts to 
normal G3RUH operation with U16C acting as the Rx 
filter for the analog input. 


Transmit audio out to Transmit Date out (TTL 
output) modification. 

Locate U18 (74HC164) pin 3 and trace going to Jumper- 
1 pin 1. Please note that Jumper-1 normally isjumpered 
from pins 2 to 3 with a header jumper. 


1. Connect wire from Jumper-1 pin 1 to D4-10 trans- 
mit data input. 

Note: On Kantronics modem, they do the same thing. 
They disconnect the output of U18A (after C34) with a 
header, and allow you to drive the output with U18 pin 
3 or the analog output from U18A determined by the 
position ofa header jumper. Ifitis desired to disable the 
audio output of the GZRUH modem, you can cut the 
trace after C34 or remove C34. I did neither and just let 
it run since I was no longer using the audio output, and 
I saw no harm in just leaving it run. 
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Lock Detector modification. 


Locate resistor pack RS-2. Itisa 100K resistor pack and 
its only purpose is to give 100K of resistance between 
pins 1&2 and 3&4. The other resistors in the pack 
are unused. The goal here is to change this resistance 
to approx. 50K, and there are a couple of ways to achieve 
this as listed below: 


1 Cut traces to RS-2 and install two 50K resistors. 
One between pins 1 & 2, and another between pins 
3 & 4. 


2 Leave everything intact and place a 100K resistor 
across pins 1 & 2, and another across pins 3 & 4, 
this will form two parallel resistor networks with 
each one offering 50K to the circuit. I used this 
method. Not much room to work on the board for 
this step and soldering is in very tight quarters. 


3 Use the unused portions of RS_2 to do the same 

thing as #2 above using shorting wires. 
Note: The value of 50K for the lock detector was chosen 
from notes given in the PacComm NB-96 manual. Ihave 
been experimenting with these values and haveachieved 
what appears to be better results with values different 
from those reported. However since I can not document 
why that is happening, and since it might be limited to 
my application, I will not go into details on what values 
Iam using. I merely point this out so that if you happen 
to notice what appears to be poor DCD detection on what 
appear to be good signals, this might be a good first place 
to look. 


Note: There were some suggestions given in the past to 
modify a Kantronics DVR2-2 to work with the NB-96 
modem at 9600 baud. These suggestions consisted of 
bypassing one resistor and changing the value of another 
in the radio. The net result was to increase the audio 
output level of the radio to the modem, and to lower the 
transmit audio input level from the modem to the radio. 
I have found that increasing the audio output of the 
radio to the modem often-times results in worse 
performance and would recommend keeping it stock. 


However, lowering the transmit drive level is required 
but it seems to make more sense to do this in the modem 
rather than in the radio. If a 47K resistor is placed in 
series with transmit audio output (internal to the modem) 
then it will duplicate Kantronics design, and will offer 
easy adjustment of transmit deviation whether you are 
using a DVR2-2 or a D4-10. Of course this is only 
necessary at 9600 baud, as when the above modifications 
are done, the output ofthe modem is TTLand not analog. 


Mark Bitterlich wa3jpy @ wb4uou .nc 
mgb@tecnet1.jcte.jcs.mil (internet) 
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NAPRA Compendium of Past Issues. 


The following pages have all of the relavent technical articles printed in past NAPRA Zero Retries and NAPRA 
Dedicated Links. The editor does not have copies of some of those issues so some good articles may be missing 
that may be included in this magazine in the future. As new issues of the Dedicated Link come out new articles 
will also be copied into this compendium. That way members will not need to be in search of back issues in order 
to find technical information. 


Disclaimer: The articles presented in this section are from the point of view of the author. They do not neces- 
sarily reflect NAPRA policy. Please keep an open mind. 
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Problems And Some Fixes For TheNET 


Copied from Zero Retries Mar 92 

I think that there are three things 
wrong with the node networking 
software systems. 

Problem No. 1 is that when you send 
data into one of these nodes, the node 
will not return an acknowledgment to 
the originating station of the packet 
until the information has been sent to 
the next node. Let's take a case where 
the node is relaying the information to 
another node or user. To visualize this, 
say that you have your local uplink LAN 
port into the network. When the datais 
received by your local LAN, that node 
first sends to the next node in the path 
to get to its destination, waits for an 
acknowledgment from that next node 
and then sends you back your 
acknowledgment. 

Problem No. 2 is that when you 
connect to a distant node and ask for a 
nodes listing, the entire listing must be 
received by each node in the connected 
path before it will be relayed to the next 
connected node, or end user. To 
visualize this, lets say that you connect 
to your local LAN node, and then connect 
to another node in the network that is 
out of your local area and that there are 
a dozen other network nodes in the path. 
When you type “N” (for example) the 
information will start making its way 
across the network to the node at which 
you made your entry into the network, 
but you do not receive any information 
from your local node until the entire 
listing has been received at your local 
network node. This means that if the 
path was working and it failed for some 
reason, you will not even get a partial 
listing. 

Problem No. 3 is when you connect to 
your local uplink node and you wish to 
connect to another node in another state 
(for example) and you issue a “C xxx” 
your packets are essentially digipeating 


from the node at which you uplinked the 
destination node. But, how can this be? 
We have been told that to avoid this is 
why the nodes were developed in the 
first place, right? Right. The problem 
comes from the way that NET/ROM, 
TheNET, and TheNET-Plus handles the 
level 3 and 4 connections. On a level 3 
connect between nodes you do get node- 
to-node-acknowledgments, but on level 
4 layer connections you're essentially 
digipeating across the network and 
backbone networks to your destination. 
This is one of the reasons why node 
hopping across the country will often be 
so difficult. Ifthere is local activity that 
is keeping the network busy in part of 
your path and your packets are trying 
to traverse that part of the network, it 
will be competing with the most 
aggressive timing parameters on the 
local connections. Another factor that 
plays here is the timing parameters. 
Nodes operate the same way your TNC 
operates, with parameters like FRACK, 
PPersistance, DWait, and RETRY, and 
if your Packets are ‘digipeating’ across 
the network in a level 4 connection these 
parameters might well time out your 
link connections before the data has 
even had a chance to be relayed back to 
your last node connection. This also is 
true for those BBS stations that 
advertise “xxxBBS”. If you should 
connect to your local node and see a 
“xxxBBS” in the nodes listing (by typing 
“N”) and see a BBS that you’d like to 
connect to but it is another state or even 
another part of your network, there 
might be a dozen or more network nodes 
in the path to get to that station and 
you're essentially digipeating the entire 
route. It would probably be best if the 
“xxxBBS” nodes were to be limited in 
the network to the area of intended 
coverage anyway and not propagating 
throughout the network and across the 


states, but that is another story. 

Best bet here is to ‘stage’ your 
connections. A knowledge of the 
network map is useful. You can also 
figure out the network your self by 
stepping through it if things are set up 
that way. For instance. First connect 
to the local LAN node, then type “N 
xxx” where ‘xxx’ is the destination 
node. The node will then reply with 
any information that is available to 
get to the destination node, such as; 
(see side bar!) 

In this example I only ventured but 
a short distance, which never left my 
house, but this very same method has 
been used for years to travel across the 
country from one state to another 
several thousands of miles away! 
While I was living in San Jose, 
California I used to be able to connect 
with nodes in South Dakota! Now that 
I’m again living back in Washington 
state I still get connections from N700 
using various VHF and HF links from 
Sierra Vista, Arizona.! You'll find that 
there are places where you can skip 
several nodes in your connect path over 
a period of time, and that there are 
others that you must connect to get 
past a place that has poor propagation 
conditions or heavy loading from BBS 
or user activity, but that your over-all 
ability to get from one place in the 
network to the other will be vastly 
improved. 

Disclaimer: NET/ROM or its 
equivalents are what we've got to work 
with, there may be other networking 
software packages out there that 
operate in a different way, but that 
doesn’t mean that this software is 
inferior. However, knowing the 
limitations will better enable you to be 
able to use the software more. 
effectively. 

—Scott Kronk, N7FSP 
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LAN Architecture or Should I use a Beam or an Omni? 


Copied from Zero Retries Mar 92 

There has been controversy since the early days of amateur 
packet radio as to whether a packeteer should use an omni or 
a beam. I'll try to resolve that in this article. I think that I 
can show that in modern metropolitan packet radio a user 
station should utilize a beam if possible. 

Most packet radio operations in the US. occur on 2 meters. 
In most situations when a packet user turns on the radio and 
TNC the station will hear other sites. Some of those other 
sites will hear yet other sites and so on. In most cases there 
will be more than one server, node, digipeater etc. on the 
frequency. Thisis far from ideal. In this case planning either 
has not taken place or has not been effective. For the purposes 
of this article I'm going to focus on LAN channels where 
planning has taken place and where we're now trying to make 
it effective. 

Fixed # of stations, all stations hear each other 

There are two LAN architectures available to users of 
current day off the shelf TNCs. The first is the same 
architecture used in commercial CSMA ethernet systems. In 
this all stations can hear each other. All are basically omni. 
All have equal priority and may make a local decision on 
when to transmit and be pretty sure of not colliding with 
another station. 

This kind of LAN is possible on Amateur Radio only where 
spectrum space is not a premium and all of the packeteers 
are in a planned region. This may be the case in a small 
community, not a major metropolitan area. 

One server, stations don't all hear each other 

The second architecture is one in which it is not possible to 
predict how many active stations can hear each other. Using 
standard TNCs the only form that this LAN can take and 
still function with better than 20% efficiency is the form in 
which 
¢ one station on the LAN can hear and talk to all of the 

other stations 
¢ that one station is the only server on the channel. 
These two points are usually the case on designed LANs 


because all of the users access one node or one server on a 
given frequency. 


Server station 
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It can be proven experimentally or via simulation that the 
only way to efficiently use a CSMA system with hidden 
transmitters requires that the total utilized channel time must 
be less than 20% of the available time. If the server is not a 
hidden transmitter to anybody then it may use as much time 
as itwants. Only the user stations need divide the remaining 
time by 5. 

In this scenario a beam should be used for all user stations 

if possible because 

e it won't affect the channel utilization calculations at 
all whether the user stations can hear each other or not, so 
long as the user stations don't transmit very much 

° and the geographic coverage of the LAN may only 
be controlled ifthe individual user stations cooperate by using 
beams. 

The two drawings show geographic area used by a LAN 
where the users have beam antennas and by a LAN where 
the users have omnidirectional antennas. 

It can be seen from the drawings that if a large group of 
people operated to a server station, using omnis, that the size 
of the LAN would be around twice as wide as the LAN where 
user stations are operating with beams. This would lead to 
one quarter then number of possible LANs on each 2m 
frequency in the metro area. 

Since the most efficient (highest data bandwidth) utilization 
of a frequency, with a given baud rate, is with a single-server 
type of LAN, the amount of data bandwidth available on a 
frequency would go up by a factor of 4 if all user stations used 
beams. (Area of a circle is mr?) 

Since most 2 meter LANs are not planned there is an 
immeasurable improvement to be gained by running cellular 
LANs, with users having beams. 

Your next phase, after you prove out the cellular concept is 
to start reducing the size of your LANs. By reducing the max 
number of stations on a LAN you increase the performance 
you give each station. Baud rate is secondary. Obviously 
having a digipeater on the highest building in the city is right 
out (hi). 

—Tadd, KA2DEW 
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New Macintosh Packet Program Released 


Copied from Dedicated Link Sept 92 

Virtuoso is a Macintosh communications program 
written specifically for packet radio. it has features that 
packet radio operators need, and also packs in a lot of 
bells and whistles to make packet radio communications 
smooth and effortless. 

The program was written by James E. Van Peursem 
KEOPH, who started his Macintosh packet radio career 
using programs written for general communications (you 
know the ones). This was okay for starting but it turned 
out to be quite a bother and he found himself spending 
more time trying to get the program to do what he wanted 
it to do than actually communicating on packet. He also 
has seen literature for other packet radio communica- 
tions programs, but the seemed to lack the power and 
ease of use that he had grown to love in a Macintosh 
program. 


James says that Virtuoso is his solution. It packs all 
of the power of the best of the programs and is written 
specifically for packet radio, so operating has never been 
easier. Some of the features now implemented are: 
¢ Powerful scripting to automate routine tasks, 
¢ Startup and exit scripts, 
¢ Save incoming text to disk file, 

e Append a selection of text to the end of an existing 
file, 

Print a selection of text, 

Find the last time you heard someone, 

Spelling checker checks words as you type them, 
Windows can be scrolled to see previous text, 
Supports full font, size, style and justification, 
Supports 300 to 9600 baud and 


¢ Automatically puts your TNC in and out of KISS 
mode. 

A channel window has two panes. The top pane con- 
tains the incoming information from your TNC. The 
bottom pane contains what you type and send to your 
TNC. The size and location of the channel window can 
be changed easily as in any other Macintosh program. 
Both panes can be scrolled up and down to see items 
that scrolled of the screen. 

A keyboard buffer window allows you to type long 
messages before they are transmitted. This window sup- 
ports the cut, pasted, clear and undo functions (like any 
good text editor). 

Users may use the control key or the option key (if 
they don’t have the control key) to send control charac- 
ters to the TNC. USers may optionally strip received 
line-feeds or all control characters before displaying and 
saving received dat to disk. CTRL-Gs can be passed to 
beep your computer if desired. 

Virtuoso is shareware, that is, it is distributed freely, 
however, if you decide that you like the program and 
keep on using it, you must pay the shareware fee of $20 
US. In order to check your spelling, Virtuoso nees a 
dictionary. This is available for $10. To register Vir- 
tuoso ($20) or to register Virtuoso and receive the dic- 
tionary ($30) write to: 


James E. Van Peursem, KEOPH 
RR #2, Box 23 


Orange City, IA 51041 
—from May 1992 Gateway/ARRL 


AA4ARE BBS Version 2.12 Available 


Copied from Dedicated Link Sept 92 

AA4RE BBS (also known as BB) version 2.12 is now 
available, according to Roy Engehausen, AA4RE. It in- 
cludes lots of new features to make your life as a SYS- 
OP easier including: 


¢ Overlay area is now shared (no more task busy), 

¢ Supports BPQHOST mode direction (BPQ v4+), 

¢ A REVIEW command, 

¢ Acommand to display routing info, 

¢ Authentication, 

¢ Call directory support, 

¢ Lots of server support, W1NPR wrote a great bunch 
of servers that do just about anything. Contact him 
for details. 
The primary advantage of BB over the other systems 

is the ability to handle multiple connections per port with 

a minimum CPU system. The programs uses it’s own 
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multitasker, so no DESQview, DoubleDos, etc. is re- 
quired. BB has been optimized for speed and requires 
at least 512 Kbytes of RAM (and usually 640 Kbytes) 
to be used productively. It runs fairly well even on an 
8088 based machine. 


BB uses a host-mode interface so either G8BPQ or 
one of the following TNCs are supported: TNC 1 and TNC 
2 (or clones) with WB8DED firmware, AEA PK87, PK88, 
PK232, and the DRSI PC*PA TNC card. Using the 
G8BPQ switch it can run with a KISS mode TNC or with 
connection to one or more TheNET TNCs. 


The file name is BB212.ZIP and is available on 
tomcat.gsfc.nasa.gov which is accessible via SLIP and 
Internet. It is also available on uscs.edu in directory 
hamradio/packet/aa4re. 


Continued on next column “+ 
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F6FBB PBBS 5.14 Released 


Copied from Dedicated Link Sept 92 

According to Markku Toijata, OH2BQZ, a new version 
of the F6FBB PBBS- software is now available via 
anonymous FTP from tomcat.gsfc.nasa.gov ornic.funet.fi 
(in Europe). The key features of this software are: 


¢ Use of the WA7MBL command set. It also has a set 
of unique supplementary commands. 


¢ Works on any 100% compatible XT or AT PC fitted 
with a hard disk and 640 Kbytes of RAM, mono- 
chrome CGA or EGA VDU, 1 to 8 serial ports. 


¢ Supports user-selectable colors or monochrome with- 
out modification. 


¢ Takes advantage of extended or expanded memory. 


¢ Supports up to 50 simultaneous channels on eight 
TNCs (4 or 8 channels per TNC depending on the 
software used). 


¢ Supports use of an external multiplexer (schematics 
available on distribution disk). It supports exten- 
sion boards ifa hardware configuration has more than 
two ports. The multiplexer connects four TNCs on 
one serial port: either COM1 or COM2. Printed cir- 
cuit boards available from: 

ATEPRA 

23 Rue de Provins 

77520 Mons en Montrois 

France 


¢ Operates with G8BPQ, any TNC 2 or clone with 
WAS8DED firmware, PK232 or KAM. 
a 


Continued from previous column 


BB can be obtained by downloading it from the fol- 
lowing BBSs: 
WAG6RDH BBS @ 916-678-1535 
WB3FFV BBS @ 410-625-9482, 410-625-9482 or 410-625-9663 
If you want BB on disk, send $5 US to: 
Dave Larton, N6JQJI 
766 El Cerrito Way, #D 
Gilroy, CA 95020-4148 
or 
John Anderson, N7IJI 
2729 Park Rd 
Charlotte, NC 28209 
Canadians can send $5 CAN to: 
ARES Group 
Attin.: REBBS Update 
PO Box 35 
St.-Jean Chrysostome, PQ G6Z 2L3 
For source code, include $2 more (for multiple dis- 
kettes). We can handle all formats of 5-1/4 and 3-1/2 
inch disks. 


The software can also be obtained via BITNET by 
sending a note to ENGE at ALMADEN 
—from Packet-Radio Digest 
—from QEX/ARRL May 1992 
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¢ It has server functions (computation of satellite or- 
bits, call directory, operator selectable chapters, gate- 
way to other channels, conferencing, etc). 


¢ Hierarchical routing is supported. 


¢ The ping-pong phenomenon is automatically detected 
and information is given to the SYSOP via a system 
message. 


¢ Messages and bulletins for the SYSOP are duplicated 
to a destination call sign that can be defined by con- 
figuration. 


¢ Adetailed log of the PBBS activity is maintained and 
a statistical analysis program, written by FC1MVP, 
is also available. 


e Provides a gateway between connected stations or 
with another port. 


¢ Supports conferencing within the limits of the avail- 
able ports and channels. 


¢ Upon connection, the connect language is attributed 
to the user depending on the user’s callsign. 


¢ RemoteSYSOP operation is supported and the house- 
keeping of the PBBS messages, mail and old mail is 
done automatically each and every night during pro- 
grammable low activity periods. 


¢ Works under DESQview. 

Message forwarding is WA7MBL-compatible and is 
optimized between PBBSs using the FBB protocol, which 
is more efficient on a VHF/UHF network. Forwarding 
also is compressed to reduce data by a factor of about 
40 to 50% in big messages. The messages are protected 
by checksums, then the transfer is made error-free. 


Forwarding is simultaneous on the various ports re- 
gardless whether they are incoming or outgoing. The 
number of simultaneous forwardings on each port is set 
by a configuration parameter. The number of incom- 
ing forwardings is a function of the available channels. 
The time and the period of forwarding can be set sepa- 
rately on each port. 


Binary transfer is supported by using the YAPP pro- 
tocol. An extension to this protocol has been made, in- 
cluding the automatic restart and the checksum should 
a stop occur or a disconnection take place during the 
transfer. This extension to the protocol works with TPK, 
the packet terminal program written by FC1EBN. 


BIDS management (over 2000 are saved in a sepa- 
rate file). A BID is automatically generated if the us- 
ers does not provide one. Private messages work with 
the management of MID. The messages are suppressed 
automatically after a delay which can be user-defined. 
This is true for bulletins and private mail. 

—from Packet-Radio Digest 
—from May 1992 Gateway/QEX/ARRL 


Page 145 


9600 baud Modifications for the ICOM IC-471A 


Copied from Dedicated Link Sept 92 
Don Lemke, WB9MJN 
24 March, 1992 


This document details the modi- 
fications necessary to operate 9600 
baud .56GFSK data modulation thru 
an Icom IC-471a transceiver. This 
is the modulation that was originally 
developed for Ham Radio usage by 
Steve Goode, KONG, and also em- 
ployed in the G3RUH and TEXNET 
modems. 


Modulator 

The IC-471a has a “Direct FM” 
Modulator. This modulator uses a 
varactor, D4 on the “MAIN” C.B. 
(Circuit Board). This modification 
patches the 9600 baud FSK Transmit 
Audio into the modulator circuit, in 
a way that transmit audio, and the 
FSK audio have minimal distortion. 
As with any 9600 baud modification 
to a “Direct FM” modulator, read- 
justment of the audio deviation is 
recommended, after the modification. 


Step 1: Replace C17 with a .47 uF, 
25 w.v. non-polarized capacitor. The 
capacitor should be physically ap- 
propriate in size. I use one that had 
a .3 inch lead spacing, was about .4 
inch square, and one eighth of an 
inch thick. 


Step 2: Attach on the bottom of the 
C.B., a 3.3 KOhm, 1/4 watt resistor 
to a C.B. trace between R30 and C17. 
Leave the far end free. 


Step 3: Attach a .001 uF, 50 w.v. 
disc ceramic capacitor to a ground 
C.B. trace near the free end of the 3.3 
KOhm resistor. Twist the free end 
of the resistor and this capacitor to- 
gether. 


Step 4: Attach a piece of small coax 
to ground, and the junction of the 
resistor and capacitor. I used RG-178 
coax. The center conductor gets at- 
tached to the components. Insulate 
the connections with Fiberglass tape, 
so that when the C.B. is reinstalled 
the connections will not short out 
against the chassis, or the C.B. 


Step 5: Solder the other end of the 
coax to MOLEX socket terminals 
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(#02-06-1103). Insert the center con- 
ductor terminal into the “Auxiliary” 
connector position number 9, and the 
ground into “Auxiliary” connector 
position number 17. This completes 
the Modulator modification. 


TX/RX Turnaround Time 
Improvement 

The stock IC-471a applies power 
to its TX’er audio stages only during 
transmit. Thus, when the trans- 
mitter comes on, RC time constants 
in these circuits cause the trans- 
mitter to drift for approximately 1 
second. To cure this problem, this 
modification reroutes the DC power 
for Q1 to a filtered +8V point, and 
enables the IC1 stages continuously. 
This modification is to the IC-471la 
“MAIN” C.B.. 


Step 1: Cut free the long lead of 
R26, which should be towards D3. 


Step 2: Solder a piece of jumper 
wire onto the free lead of R26, and 
insulate connection with heat shrink 
tubing. 

Step 3: Solder the far side of the 
jumper wire to IC1, pin 8. 


Step 4: Solder another piece of 
Jumper wire to IC1, pin 8 and far end 
of this wire to the junction of D1 and 
R4. This completes the TX/RX 
Turnaround Time Improvement 
modification. 


Receiver FSK Audio 

The IC-471a uses a MC3357P 
Receiver IF chip. The discriminator 
output of this chip has a low enough 
impedance that it can directly drive 
a shielded wire without the signal 
being distorted. In addition, this 
audio signal is provided an unused 
C.B. header, J14 on the “MAIN” C.B. 
which is easily used to connect the 
signal to the rear panel “Auxiliary” 
connector. 


Step 1: Obtain a .1 inch spacing, 
2 position, socket which will fit onto 
J14 and solder subminiature coax to 
the socket, so that the center con- 
ductor socket will mate with the J14 
pin on the “R214” side of J14. The 
ground lead is soldered to the other 


position of the socket. The MOLEX 
catalog shows a part number 22-01- 
2026 for the connector housing, and 
it requires 2 type 4809c terminal 
inserts. 


Step 2: Solder a MOLEX socket 
terminal (#02-06-1103) onto the other 
end of the coax, ground lead. 


Step 3: Solder a .47 uF, 25 w.v. 
capacitor to another MOLEX socket 
terminal. Connect the coax center 
conductor to the other lead of the .47 
uF capacitor, and insulate this con- 
nection with heat shrink tubing. 


Step 4: Insert the coax ground 
conductor terminal into the “Auxil- 
iary” connector pin 15, and the ca- 
pacitor terminal into pin 11. 


This completes the receiver FSK 
audio modification. Bringing it all 
together: The MOLEX part number 
for the “Auxiliary” connector mate is 
03-06-2241, and the pin terminal part 
number is 02-06-2103. The connector 
has 24 pin terminal positions, so if 
you plan on using all these positions 
someday, order 24 of the 02-06-2103 
part number. 


Comments on filters 

The IC471a has the ideal Receiver 
IF BW for 9600 baud operation. As 
part of this project I measured the 
Receiver IF BW to be 14 KC at -6 dB. 
The 455 KC Filter part number spec 
is 15 KC BW at -6 dB. The IC471a 
also has a crystal filter for the 
transmitted signal. On the RF. YGR 
C.B., FL2, a part number 70M15A, 
is part of the transmitter. The part 
number indicates the filter is 15 KC 
wide at 6 dB down, I believe. The 
effect of this filter is to reduce the 
single bit transitions of the KING 
modulation, by a small amount and 
time delay distort the signal a small 
amount. AllI can report, is that this 
is not causing a big problem here on 
the terrestrial 9600 baud LAN, 
where other users have TEKK and 
IC-475a radios. The IC-475a has this 
same filtering. I am looking to re- 
place this filter with a 20 or 25 KC 
wide at 6 dB down filter. In a com- 
plete transmitter to receiver path, the 
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signal passes two time delay distort- 
ing filters, of the best BW for detec- 
tion, for these type of filters. This de- 
optimizes things some. This report 
will be sent thru the IC-471a, 9600 
baud station here, to the network, 
however. Illustrating that the effect 
is small. 


IC-471a problems 

This IC-471a was used when I 
obtained it. Looking at the manual 
spec for receiver sensitivity, of .5 uV 
for 20 dB Quieting, many of you 
might cringe. After looking at the 
receiver line up, and the parts used, 
this performance seemed somewhat 
odd. This is not a radio with a 6 stage 
helical resonator front end filter, and 
J-fet mixer! That type of radio would 
typically give the IC-471a’ specified 
performance. The IC-471a is de- 
signed to have considerably better 
sensitivity than this, although ob- 
viously at the expense of front end 
overload handling. Something is 
wrong. Measurement of my used IC- 
471a showed that besides the pro- 
duction and/or design problem I 
suspected, something was really 
wrong with my particular radio. The 
sensitivity varied dramatically with 
temperature. It would start out on 
spec, then slowly get as bad as -90 
dBM for 20 dB quieting. This is 
BAD! I tracked the variable sensi- 
tivity to a problem in the PLL box. 
As the unit warmed up, its output 
would vary from around .75 vrms to 
less than .1, on center band. I never 
“fixed” the PLL, but by removing the 
cover, and putting 1/4 inch spacers 
between the PLL enclosure and the 
module that is mounted over the PLL 
box, the PLL stabilized with enough 
output, that near spec sensitivity was 
maintained. Next I went after the 
poor spec. While finger testing L29, 
the sensitivity improved, greatly. 
After replacing L29 with a new coil, 
with an additional turn (3 instead of 
2), and the sensitivity improved 
about 20 dB. A 20 dB quieting sig- 
nal needed less than -110 dBM, 
which is about .2 uV. This is the typi- 
cal range for UHF receivers of this 
design! L29 is part of a PI circuit 
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used to transform the PLL output im- 
pedance of 50 ohms to a very high 
voltage and impedance needed by the 
first receiver mixer stage, Q12. At 
this sensitivity, with a 19 element 
F9FT Yagi, UO14 9600 baud was 
very easy to copy for most of the pass, 
even without a preamp. I include 
these experiences in this article on 
how to do 9600 baud packet, to hope- 
fully make it clear to people that even 
a pretty looking radio can perform 
like garbage, and that if the radio 
isn’t working in the first place, the 
9600 baud packet radio is not going 
to either. Nobody should expect that 
they will be able to do 9600 baud 
Packet radio, with existing rigs, like 
they would do 9600 baud telephone 
line communication. Yes, you may 
actually need to learn and do some 
hardware electronics to do this. 


Concluding remarks: 

With these modifications, the IC- 
471a makes a nearly ideal 440 band 
9600 baud packet radio. I’ve used 
mine on UO 14, as a receiver, as well 
as over our 9600 baud terrestrial 
LAN. A PING test thru N4PCR-0/ 
1, which uses a TEKK radio, and 
preamp, and one of the CELLNET 
56 KB, FDX radios described in the 
file CELLNET.UPT, to the K9VXW- 
1 node, where the other CELLNET 
prototype FDX radio is, passed 98 of 
100 kilobyte packets with the NOS 
Window = 2048, MSS = 216. I hope 
this article is helpful, and will en- 
courage some of you to take the 
plunge and try out 9600 baud packet 
radio. 


All commercial use of the infor- 
mation developed by the author in 
this article is reserved. Like some- 
body said, “I’m not making money at 
this, and I don’t want you to make 
money off me either”. In other words, 
you are free to do these modifications 
for yourself, or have somebody do 
them for you, if he or she gets noth- 
ing in return for it. 

73, Don WBOMJN @ 
NOHSI.IL.USA.NA or 
wb9mjn%wb9mjn.ampr.org 
@ke9yq.imsa.edu 


Kenwood TS-450S 
Grounded 


Copied from Dedicated Link Sept 92 

For over two weeks, Dick Kriss, 
KD5VU, tried to interface a new Ken- 
wood TS-450S to an AEA PK- 
232MBX using the 13-pin DIN plug 
(CCY2) on the rear of the TS450S. 
But, a feedback loop fouled-up the 
transmit SSB audio whenever the 13- 
pin connector was attached. Dick 
finally found a fix. 


He followed the old ham rule that, 
if all else fails, ground it. So, he ran 
a “real” ground wire from the ground 
lug on the rear of the TS-450S to the 
PK-232 circuit board using the top- 
Oside screw for the right-rear 
mounting foot (near the 12-vold input 
connector). The SSB transmit audio 
problem is history. 


Although the PK-232 was already 
grounded using the wire in the AEA- 
supplied cable, Dick suspects some- 
thing is amiss with the grounds in 
the TS-450S ACCY2 port. He is not 
sure why the new ground wire works, 
but the price was right and the PK- 
232 and TS450S are now working 
fine. 

—from Dick Kriss, 
KD5VU@N5LJF.Saus.tx.usa.na 
—from May 1992 Gateway/QEX/ 
ARRL 
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Interfacing PacCom NB-9600/G3RUH modem 
to Kantronics D4-10 


Copied from Dedicated Link Sept 92 

Due to numerous requests, I am posting modification 
instructions for the Paccom NB-9600 G3RUH modem 
to convert it to TTL input/output to drive a Kantronics 
D4-10 at 19.2Kbaud. Don’t forget to change the radio 
speed jumpers in whatever TNC you are using to 19.2K 
after these mods are done. 


I mention this only because I spent one hour trying 
to figure out why my mod wouldn’t work, only to finally 
realize I never changed the TNC speed to 19.2K to drive 
the blasted modem! (what an idiot huh?) It’s the simple 
things that getcha! :-) 


5 Feb. 92 


All part numbers given are for the Paccom NB-96 
modem. 


Receive audio in to receive data in (conversion 
to TTL input) mod. 

Locate U10 pin 2, and circuit board trace going to U5 
pin 2. 


1 Disconnect output of U10 pin 2 by either lifting the 
lead leg on the integrated circuit or by cutting trace. 
Lifting the leg on the IC is the easiest way to go 
about it. 


2 Connect TTL receive data input from the D4-10 to 
trace going to U5 pin 2. 

Note: On Kantronics 19K2/9K6 modem, they actually 
put in a jumper that lets you either drive U5 pin 2 di- 
rectly from a TTL source (such as the D4-10) or when 
the jumper is installed, the input to this stage reverts 
to normal G38RUH operation with U16C acting as the 
Rx filter for the analog input. 


Transmit audio out to Transmit Date out (TTL 
output) modification. 

Locate U18 (74HC164) pin 3 and trace going to 
Jumper-1 pin 1. Please note that Jumper-1 normally 
is jumpered from pins 2 to 3 with a header jumper. 


1. Connect wire from from Jumper-1 pin 1 to D4-10 
transmit data input. 

Note: On Kantronics modem, they do the same thing. 
They disconnect the output of U18A (after C34) with a 
header, and allow you to drive the output with U18 pin 
3 or the analog output from U18A determined by the 
position of a header jumper. If it is desired to disable 
the audio output of the G3RUH modem, you can cut the 
trace after C34 or remove C34. I did neither and just 
let it run since I was no longer using the audio output, 
and I saw no harm in just leaving it run. 
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Lock Detector modification. 

Locate resistor pack RS-2. It is a 100K resistor pack 
and its only purpose is to give 100K of resistance between 
pins 1&2 and 3&4. The other resistors in the pack 
are unused. The goal here is to change this resistance 
to approx. 50K, and there are a couple of ways to achieve 
this as listed below: 


1 Cut traces to RS-2 and install two 50K resistors. 
One between pins 1 & 2, and another between pins 
3 & 4, 


2 Leave everything intact and place a 100K resistor 
across pins 1 & 2, and another across pins 3 & 4, 
this will form two parallel resistor networks with 
each one offering 50K to the circuit. I used this 
method. Not much room to work on the board for 
this step and soldering is in very tight quarters. 


3 Use the unused portions of RS_2 to do the same 
thing as #2 above using shorting wires. 

Note: The value of 50K for the lock detector was chosen 
from notes given in the Paccom NB-96 manual. I have 
been experimenting with these values and have achieved 
what appears to be better results with values different 
from those reported. However since I can not document 
why that is happening, and since it might be limited to 
my application, I will not go into details on what val- 
ues I am using. I merely point this out so that if you 
happen to notice what appears to be poor DCD detec- 
tion on what appear to be good signals, this might be a 
good first place to look. 


Note: There were some suggestions given in the past 
to modify a Kantronics DVR2-2 to work with the NB- 
96 modem at 9600 baud. These suggestions consisted 
of bypassing one resistor and changing the value of an- 
other in the radio. The net result was to increase the 
audio output level of the radio to the modem, and to lower 
the transmit audio input level from the modem to the 
radio. I have found that increasing the audio output of 
the radio to the modem often-times results in worse 
performance and would recommend keeping it stock. 


However, lowering the transmit drive level is required 
but it seems to make more sense to do this in the mo- 
dem rather than in the radio. If a 47K resistor is placed 
in series with transmit audio output (internal to the mo- 
dem) then it will duplicate Kantronics design, and will 
offer easy adjustment of transmit deviation whether you 
are using a DVR2-2 or a D4-10. Of course this is only 
necessary at 9600 baud, as when the above modifica- 
tions are done, the output of the modem is TTL and not 
analog. 


Mark Bitterlich wa3jpy @ wb4uou .nc 
mgb@tecnet1 .jcte.jcs.mil (internet) 
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Quality Values vs TheNET Node Propagation Distance 


Copied from Dedicated Link Sept 92 

NAPRA specifies a node propagation distance of 7 
hops. That-means that 7 TNCs away from a node the 
node will be visible but 8 TNCs away it will not. As- 
suming that each TNC to TNC over the radio hop is a 
point to point link and each TNC to TNC local hop is 
over a HexiPus™ each node site will be visible three node 
sites away. The reason for this number is : 


¢ Ifthe network is built well and if networking is at all 
popular the number of nodes that will be three node 
sites away starts approaching 100. Four node sites 
away will reach a number correspondingly higher. 
Keeping node lists short, is for TheNET a good idea 
for many reasons. 


e By reducing the number of sites each connect com- 
mand can traverse we improve the reliability of each 
connection. 


° Because the quality value of a node is reduced dras- 
tically with each hop if a link goes down the node's 
which are no longer available disappear fairly quickly. 
This also goes for nodes which are placed on the air 
temporarily. 

NAPRA makes the recommendation of 203 for a broad- 
cast quality for both RS-232 and radio links for all 
TheNET nodes and 161 for all single CPU nodes (like 
G8BPQ, MSYS, NOS). 


The value used for Time-To-Live is used to limit the 
number of hops that a transmission may travel across 


the network. This is useful for reducing the effect of bad 
routing which occurs when a link fails. If'Time-To-Live 
is set to a value less than the number of hops that a node 
may propagate (set by the quality values) then users may 
attempt to connect to nodes that can not be gotten to. 
This causes immense frustration. Please do not allow 
nodes which are unreliably connectable to show on the 
lists of nodes that are in your control. By keeping your 
node lists down to what is usable you do a great service 
for packet radio. Users are our future. 


Use this program to determine how far your nodes 
will propagate. If Time-To-Live is set too low, either set 
your quality values lower, set Time-To-Live higher, or 
re-think how things are working. 

—KA2DEW 
10 msgqual = 256: 
20 hopnum = 0: 


rem initial value for a node 

rem we haven't started hopping yet 
30 minqual=50: rem minimum quality for all nodes 
40 RAIN aie te rem blank line 

50 PRINT “at start node" 

REM start of loop 

110 PRINT "message qual at hop #";hopnum;"=",;msgqual 


120 INPUT "Enter quality for this hop ->";hopqual 
130 msgqual = msgqual * (hopqual / 256) 

140 msgqual = INT(.5 + msgqual) 

150 hopnum=hopnum + 1 

160 IF msgqual < 50 THEN 2000 

170 “GOTO100 

2000 REM end sequence 


2010 PRINT "message quality is below min-qual." 
3000 END 


New TAPR kits introduced 


Copied from Dedicated Link Sept 92 

Tucson Amateur Packet Radio (TAPR) introduced two 
new kits at it’s annual meeting: a 9600-bit/s modem and 
a satellite tracking antenna controller 


9600-bit/s Modem 

The new 9600-bit/s modem kit incorporates many 
enhancements over the KING modem kit which has been 
available at TAPR for several years. The new kit offers 
full-duplex operation, improved transmit spectrum, im- 
proved clock recovery, DCD and an optional bit regen- 
erator for use as a full-duplex 9600-bit/s repeater. An 
optional clock is available for stand-alone bit regenerator 
usage or elsewhere where not provided by the TNC. The 
modem connects to the standard TAPR modem discon- 
nect header and fits inside a TNC 2, PK-232 and many 
other TNCs. The kit costs $70 including shipping and 
handling in the US. The bit regenerator option is $10 
and the clock option is $5. 
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Satellite Tracking Antenna Controller 

By arrangement with JAMSAT, TAPR is offering in 
KIT form the TrakBox developed by SMOTER, JAGFTL 
and others. This requires a computer or terminal to enter 
the Keplarian data. It has an LCD display and runs 
stand-alone after loading the data. It directly controls 
the Kenpro/Yaesu rotators and can be adapted for other 
types. It also provides Doppler correction for the Ken- 
wood, ICOM and Yaesu radios that are used for satel- 
lite communications. The kit costs $185 including ship- 
ping in the US. 
Both kits are available now from 
TAPR 
PO Box 12925 
Tucson, AZ 85732 
602 749-9479 Tues.-Fri, 1OAM -3PM MST 
Bob Neilsen, W6SWE, 
via Compuserve’s HamNet 
from May 1992 Gateway/QEX/ARRL 
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Notes on FT736 & 9600 Baud Operation 


by James Miller G3RUH 
Copied from Dedicated Link Sept 92 


These notes tell you where to get FM RX audio di- 
rect from the discriminator, and where to modulate the 
FM TX varactor directly. These mods are non-destructive 
and take no more than a few minutes. The signal by- 
pass the "DATA SOCKET" for high grade FM operations. 
The RX mod is suitable for: 
¢ UOSAT-D 9600 baud downlink and terrestrial links 
¢ 1200 baud AFSK/FM Standard Packet - BUT IT'S 

UNSQUELCHED. 

The TX mod is suitable for: 

¢ FO-20/PACSAT uplink (1200 bps Manchester FM) 

¢ UOSAT-D 9600 baud uplink direct FSK and terres- 
trial links 


¢ 1200 baud AFSK/FM Standard Packet. 


FT736 - FM Direct from Discriminator 
Detected FM direct from the receiver discriminator 
is available from the RX UNIT at the junction of R91 
and C83. These components are shown in the top right- 
hand corner of the schematic. 


Proceed thus: 

1 Disconnect FT736 from the mains electricity. 
(Safety). 

2 Remove top cover only. 

RX Unit is the vertical module on the left. 


4 Locate R91 which is about 25mm from the top, 
50mm from the radio rear. The resistor is "on-end", 
and near a couple of glass diodes. 


oo 


5 Scrape any paint off R91's free end and wet with 
solder. 


6 Your RXaudio lead should be a fine screened cable; 
connect the inner to R91, and the outer braid to a 
ground point (e.g. can of TO09) 

7 Route the cable out though any convenient aper- 
ture in the case. 


8  Thediscriminator sensitivity (FM Normal) as about 
6 kHz/volt. 


Important note on 9600 Baud Use 

Some FT736 receivers are fitted with an LFH12-S IF 
filter for FM. (CF01 at the top front of the RX Unit). This 
is a 12 kHz bandwidth filter which is a little too nar- 
row for 9600 bps FSK operation. It is recommended you 
change this to 15 kHz or better still for UOSAT-D use, 
20 kHz bandwidth which will allow more tolerance for 
doppler shift, and give a far better "eye". Suitable fil- 
ters are: LFH-15S or CFW455E, and LFH-20S or 
CFW455D. The first of these is a Yaesu spare part, and 
is often already fitted. 
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FT736 Direct Varactor FM Modulation 
Refer to the circuit diagram; inject your TXaudio at 
the junction of R32/C29 on the TX Unit. The signal level 
at this point should be 800 mV peak-peak, and will give 
+/- 3 kHz deviation. Do not exceed this level. 


Set Mic Gain to min. 


Modulating the FM transmitter this way you get an 
LF response down to 18 Hz (at which point the associ- 
ated synthesizer PLL begins to track the modulation), 
and an HF response which is flat to some 10 kHz. 


Proceed thus: 


1 Disconnect FT736 from the mains electricity. 
(Safety). 


2 Remove top cover only. 


3 TX Unit is the module flat on the left (not the one 
tucked down the side vertically). 

4 R82 is just to the left of the rectangular shielded 
enclosure. The resistor is "on end". Scrape any paint 
off the free leg. 


5 Your TXaudio lead should be a fine screened cable; 
connect the inner to R32, and the outer braid to the 
adjacent enclosure. 

6 Route the cable out though any convenient aper- 
ture in the case. 


7a 1200BAUD PSK MODEM: TXaudio of 800 mV pk- 
pk can be obtained by adjusting the components 
C9= luf, R3=47k, R5=infinity (G.e. remove). C10 
stays at 10nf(0.01uf). 

7b 9600 BAUD FSK MODEM: Adjust TXaudio level 
with VR1 

Notes compiled by GZBRUH @ GB7SPV 1990 Mar 16 


Modification to the Yaesu FT-736R 
by G4WFQ 12/1/91. 


This modification was given to me by Zeno Wahl, 
GONJC/VE3LMX (U.0O.S) 


The modification lowers the frequency response to 3 
HZ, and gives a far better "eye" by reducing L.F flut- 
ter. 


Proceed thus. 


1 Locate "TIXPLL UNIT" (Vertical board on Tx unit). 


2 Locate R01 (Scrape any paint off. Wet component 
with FINE solder. 


3 Solder 560ohm Resistor on RO1 (end nearest to pll 
board) Solder 47microfarad tantalum in series with 
560R. Take (-) negative leg of Cap to Gnd, eg case 
of Txpll unit. 

—G3RUH & G4WFQ 
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Interfacing PacComm NB-9600/G3RUH modem 
to Kantronics D4-10 


Copied from Dedicated Link Sept 92 

Due to numerous requests, I am posting modification 
instructions for the PacComm NB-9600 G3RUH modem 
to convert it to TTL input/output to drive a Kantronics 
D4-10 at 19.2Kbaud. Don’t forget to change the radio 
speed jumpers in whatever TNC you are using to 19.2K 
after these mods are done. 


I mention this only because I spent one hour trying 
to figure out why my mod wouldn't work, only to finally 
realize I never changed the TNC speed to 19.2K to drive 
the blasted modem! (what an idiot huh?) It’s the simple 
things that getcha! :-) 

5 Feb. 92 


All part numbers given are for the PacComm NB-96 
modem. 


Receive audio in to receive data in (conversion 
to TTL input) mod. 

Locate U10 pin 2, and circuit board trace going to U5 pin 
ae 


1 Disconnect output of U10 pin 2 by either lifting the 
lead leg on the integrated circuit or by cutting trace. 
Lifting the leg on the IC is the easiest way to go 
about it. 


2 Connect TTL receive data input from the D4-10 to 
trace going to U5 pin 2. 

Note: On Kantronics 19K2/9K6 modem, they actually 
put in a jumper that lets you either drive U5 pin 2 
directly from a TTL source (such as the D4-10) or when 
the jumper is installed, the input to this stage reverts to 
normal G3RUH operation with U16C acting as the Rx 
filter for the analog input. 


Transmit audio out to Transmit Date out (TTL 
output) modification. 

Locate U18 (74HC164) pin 3 and trace going to Jumper- 
1pin 1. Pleasenote that Jumper-1 normally isjumpered 
from pins 2 to 3 with a header jumper. 


1. Connect wire from Jumper-1 pin 1 to D4-10 trans- 
mit data input. 

Note: On Kantronics modem, they do the same thing. 
They disconnect the output of U18A (after C34) with a 
header, and allow you to drive the output with U18 pin 
3 or the analog output from U18A determined by the 
position ofa header jumper. Ifitis desired to disable the 
audio output of the GJRUH modem, you can cut the 
trace after C34 or remove C34. I did neither and just let 
it run since I was no longer using the audio output, and 
I saw no harm in just leaving it run. 
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Lock Detector modification. 

Locate resistor pack RS-2. Itisa 100K resistor pack and 
its only purpose is to give 100K of resistance between 
pins 1&2 and 3&4. The other resistors in the pack 
are unused. The goal here is to change this resistance 
to approx. 50K, and there are a couple of ways to achieve 
this as listed below: 


1 Cut traces to RS-2 and install two 50K resistors. 
One between pins 1 & 2, and another between pins 
3 & 4. 


2 Leave everything intact and place a 100K resistor 
across pins 1 & 2, and another across pins 3 & 4, 
this will form two parallel resistor networks with 
each one offering 50K to the circuit. I used this 
method. Not much room to work on the board for 
this step and soldering is in very tight quarters. 


3 Use the unused portions of RS_2 to do the same 

thing as #2 above using shorting wires. 
Note: The value of 50K for the lock detector was chosen 
from notes given in the PacComm NB-96 manual. Ihave 
been experimenting with these values and have achieved 
what appears to be better results with values different 
from those reported. However since I can not document 
why that is happening, and since it might be limited to 
my application, I will not go into details on what values 
Iam using. I merely point this out so that if you happen 
to notice what appears to be poor DCD detection on what 
appear to be good signals, this might be a good first place 
to look. 


Note: There were some suggestions given in the past 
to modify a Kantronics DVR2-2 to work with the NB- 
96 modem at 9600 baud. These suggestions consisted 
of bypassing one resistor and changing the value of an- 
other in the radio. The net result was to increase the 
audio output level of the radio to the modem, and to lower 
the transmit audio input level from the modem to the 
radio. I have found that increasing the audio output of 
the radio to the modem often-times results in worse 
performance and would recommend keeping it stock. 


However, lowering the transmit drive level is required 
but it seems to make more sense to do this in the modem 
rather than in the radio. If a 47K resistor is placed in 
series with transmit audio output (internal to the modem) 
then it will duplicate Kantronics design, and will offer 
easy adjustment of transmit deviation whether you are 
using a DVR2-2 or a D4-10. Of course this is only 
necessary at 9600 baud, as when the above modifications 
are done, the output ofthe modem is TTLand not analog. 


Mark Bitterlich wa3jpy @ wb4uou .nc 
mgb@tecnet1 jcte.jcs.mil (internet) 
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Callsign server at WORLI 


Copied from Dedicated Link Sept 92 

WORLI has a nifty new feature for his BBS. He has 
an on-line callbook server. You can get data from it in 
two ways. One is to send a message to the BBS from 
your local BBS. The message format is either 
SP HB @ WORLI 


wbldsw 
n0an 


or 
SP SAM @ WORLI 


wbldsw 
n0an 


Each desired call must appear on a separate line. 
There should not be anything else in the message. The 
server will determine from the header where to return 
the answer. The response includes name and address. 


The second access method is to connect to the NODE 
WLINN (not the bbs!) The issue the command: QTH 
calll call2 call3 


Some other commands exist, but they operate quite 
slowly: 
QTH NAME first last 
QTH CITY city state 
QTH ZIP zip 
ZIP allows wildcards. 
For example: QTH ZIP 97* will provide a list of all 


hams in Oregon. Be careful of these last ones as they 
could result in large volumes of data! 


—KA7EHK, JIM WAGNER 
copied from Operator v3#22 Jan 1 1992 


example: QTH NAME JOE JONES 
example: QTH CITY PODUNK MT 
example: QTH ZIP 97389 


JNOS BBS 


Most NOS implementations include a BBS function 
which looks a lot like a WORLI or AA4RE style BBS. 
Many packeteers and most BBS ops have a rather nega- 
tive view of BBSs based on KA9Q’s TCP/IP implemen- 
tation (which all NOS versions are). That image should 
be undergoing a major change with the BBS addition 
by WG7J. I have been watching its development in 
Corvallis where it is the BBS accessible from the CRV 
node. 


First, perhaps, we might ask, “why, in heaven’s sake, 
another BBS program?” The reason is that BBS pro- 
grams which offer TCP/IP connectivity are few. MSYS, 
which attempts to do this, has flaws when viewed from 
a TCP/IPer perspective. WG7J has also added enhance- 
ments which will make his program stand on it’s own 
in the BBS arena. 


Johan (WG7J)’s version of TCP/IP operates for a long 
period of time without human intervention for restarts. 
Periodic crashes due to memory usage bugs has been 
known to be standard fair for MSYS and NOS in the 
past. Not so with WG7J’s version. WG7J’s NOS behaves 
as a node if desired (somewhat like MSYS). Johan has 
made the node interface more normal to users and im- 
proved the BBS so that it provides standard forward- 
ing. The result is a program which occupies much less 
memory space than MSYS, which implements TCP/IP 
properly, and is a BBS with some differences. 


The differences will be quite noticeable to anyone who 
uses any of the standard packet BBS programs. The 
most obvious is the area concept which is standard with 
land-line BBS operations including CompuServe. This 


Page 152 


saves you from going through all of those for-sale bul- 
letins when all you want to see is ARRL or RACES. The 
BBS places bulletins into these areas (which are speci- 
fied by the SYSOP). The BBS will tell you what the 
predefined areas are if you send it an a or areas. Do- 
ing this on CRVBBS gives me: 


a 
Current message area is: ka7ehk 


Available areas are: 


ka7ehk Your private mail area 

allor = All of Oregon stuff 

allusa - ALLUSA bulletins 

allusw - ALLUS-WEST bulletins 

amsat ~ AMSAT bulletins 

ares - A.R.E.S. bulletins 

arr] - ARRL bulletins 

ax = DX bulletins 

Eee = F.C.C. related issues 

help - help about this system 

humor - humorous stuff (whatever that 
means :-) ) 

ntslocal - Corvallis area NTS traffic to be 
delivered 

osuarc = Oregon State University ARC stuff 
pnw . Pacific North West stuff 

races - RoAj~Csas. OULLCEIOS 

sale - ‘for sale’ bulletins 

tcpip = TCP/IP related stuff 

wanted - ‘wanted’ bulletins 


Note that you have an area all of your own; each time 
you log on, you start in your personal area. To call up 
any other area, just send, for example “a allusa”; in this 
case, the response is: 

a allusa 


allusa: 
B 


131 messages - O new. 


Continued on next column “» 
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Ramsey FX-146 2m rig 
Copied from Dedicated Link Sept 92 
This article is intended for anyone planning to build 
or having already built, the Ramsey FX-146 radio kit. 


The front end of the radio is very wide, from 130-160 
MHz, which for some seems to be a blessing, but per- 
sonally, I have had more than my share of intermod 
products and image frequencies wiping out the data/ 
information/QSO I want to pursue, and so, finally called 
Ramsey with a question about the radio's bandpass fil- 
ter. As it turns out, there is a filter circuit that is available 
from them (it was free at the time, so ask them about 
it) that will replace the existing front end filter circuits. 
You remove several parts and mount the small board 
in place of those parts. The change was immediate and 
immense! Ino longer pick up the local police, fire, pag- 
ing systems and general taxi-cab calls found within the 
business band (bleeding over into my ham radio!) My 
packet system is working 1000% better, and I can now 
hear stations that are a total of five miles away (Hi Hi!) 
Not to mention stations I didn't know existed, simply 
because the interference wiped them out. Anyway, this 
mod works great, and if you have one of these rigs you 
owe it to yourself to call them and request the mod, even 
if you don't need it in your area, you might someday. 
By the way, I live in Colorado Springs, not really known 
as a high density radio area, but, apparently it is. [hope 
this helps someone else. 


—Rick NONJY @ WOLKD 


Continued from previous column 


In the event an area is empty, there is only the “>” 
response. An “L”, gives you all of the new messages in 
that area. The BBS keeps track of the “new” messages 
for each user in each area. Any (new or old) can be read 
with R #. You can S, SP, SB, etc. to your heart’s con- 
tent in any area. “LM?” (list mine) and “RM” (read mine) 
work only in your personal area. One of the quirks of 
this BBS is that the message numbers change as old ones 
are deleted; the oldest message in a given area is always 
# 1! Sysops might like the fact that version 1.01 now 
includes automatic message and old bid expiry. 


If you want more information about this version of 
KA9Q-NOS, contact WG7J@ WG7J.OR.USA.NOAM. It 
is also available on Internet and several land-line BBS’s. 
I can recommend it quite highly. The node “shell” is also 
well thought out, and, when used, is very straight for- 
ward. Sorry, but this is PC compatible only! 


—Jim Wagner, KA7EHK 
copy from the Operator via packet radio 
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What's A DataEngine? 
Copied from Dedicated Link Sept 92 
Several of our Northwest Oregon nodes are now us- 
ing DataEngines. At this moment, they include PDX7, 
CREST, SALEM, WLYNN. NPT has one expected to 
go on line soon. SNOPK has another. What are these 
machines? 


Lets first review what is a TNC. Though perhaps not 
obvious, a TNC has two parts. One is a “modem” which 
converts digital signals to/from a form suitable for ra- 
dio transmission. In the case of the 1200 baud which 
most of us use, the signal suitable for radio transmis- 
sion is AFSK (two audio tones switched back and forth). 
The other part is a little harder to explain; it might be 
called “serial-HDLC converter”. It converts between non- 
synchronous RS-232 serial & HDLC. Non-synchronous 
serial means that characters can come at any time. 
HDLC refers to characters which are formatted into pack- 
ets and are sent in a synchronous stream for at least a 
whole packet. We need not go into the formatting of pack- 
ets; that is another issue and lots of references explain 
it in some detail for those so inclined. The standard TNC 
has one RS-232 port (the terminal interface) and one 
HDLC port (the RF port). 


OK, so if that is a TNC, what is a DataEngine? First, 
a DataEngine also has an RS232-HDLC converter. 
Unlike a standard TNC, instead of 1 HDLC port, there 
are 2. The modem part of a DataEngine uses plug-in 
modems which are designed for the baud rate of the port. 
There are locations for 2 modems on the PC board. It 
is possible to have each port run at a unique baud rate. 
That gets the node to “dual-port”. A third port can be 
obtained by attaching a standard TNC to the serial port. 
The TNC is set up to operate in “KISS mode” (more about 
KISS in another article). 


To get 4 or more ports, there are several ways one may 
go. Two DataEngines may be coupled together at their 
serial ports, just like 2 TNCs in a node. This gives (a 
rather expensive) 4 port node. An alternative is to connect 
several TNCs on a “party-line” RS-232 buss at the 
DataEngine’s serial port. To do this, the TNCs must 
use “multi-drop KISS” (an EPROM-only KISS version). 


Well, then, why the DataEngine when TNCs are used 
for radio ports, anyway? Where a DataEngine shines 
is interfacing between networks running at different baud 
rates. The node problem is more than “Do I have the 
right modem?” There also needs to be a lot of memory 
(buffer) because things will come in on the highest speed 
port faster than it can go out other ports. Thus, data 
needs to be saved until it moves out. This is more effi- 
ciently handled than in standard TNCs. 


Other uses for DataEngines 

A DataEngine can work in many modes. It can “look 
like” a standard TNC2, a KISS-mode TNC, a TheNET 
node, a WA8DED “host mode TNC”, etc. 


—KA7EHK, Jim Wagner 
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KISS: What Is It and How Do I Get Out of It? 


Copied from Dedicated Link Sept 92 

Over the last several years there have been a num- 
ber of BBS messages along this line: J put my TNC into 
KISS mode and can’t get it out. What do I do? 


KISS is an acronym for “Keep It Simple Stupid!” It 
is the name of a protocol designed for TNC that allows 
the TNC to be totally controlled by a computer (like a 
PC). It is used for TCP/IP as well as for some BBS pro- 
grams. KISS messages always start with the charac- 
ter $CO (not a standard ASCII character) and end with 
a $CO. The second character is a command byte which 
indicates the kind of message. Some messages set things 
like TXDelay. Others indicate that data (i.e., a packet 
frame) is to be carried. A TNC operating this way re- 
lies on the host computer to construct the packet (in all 
of its gory details). The TNC simply converts the packet 
from asynchronous serial to synchronous. 


It is not possible to generate KISS messages from a 
7 bit terminal. There are a number of programs which 
interface with TNCs using KISS including TCP/IP, NOS, 
MSYS and G8BPQ. 


Most TNC2 clones now come with KISS resident in 
the EPROM. For MFJ1270/1274 TNCs, the command 
is KISS ON. The second step is a TNC reset. This is 
done either with a RESET command or by turning off, 
then back on. The TNC comes back on in KISS mode. 


It appears to come up at the same (terminal) baud rate 
that it was at prior to the reset. Note that once KISS 
is on, it no longer recognizes your normal computer and 
KISS OFF has no effect! 


I do know of three ways to get your TNC back into 
normal operation: 


¢ use a KISS computer interface; This involves running 
a computer program on your personal computer that 
talks KISS and asking your computer to take the TNC 
out of KISS mode. 


¢ Allow the battery-backed RAM to discharge. This can 
be done by disconnecting the battery with the TNC off. 
On MFJ TNCs, it may be easiest to slide a piece of paper 
between the battery and the battery contact then letting 
it sit for 10 minutes. 


¢ Ona PC Compatible, hold down the ALT key and type 
192 let up on the ALT key. Press the ALT key, type 255, 
let up on the ALT key. In other words: ALT-192, ALT- 
255. You must use the numeric keypad numbers 
on an IBM compatible. This is an old trick. It’s 
sending a two byte character sequence equivalent to 
decimal 192 and 255. 


Thanks to Stu, WD4ECK for the ALT key sequence tip. 
He heard it from a friend on the AMSAT net that meets 
on 80 meters every Tuesday night... 


—Jim Wagner - KA7EHK @ WG7J 


Care and Feeding of TNC Batteries 


Copied from Dedicated Link Sept 92 

Do you ever really look at your TNC? It probably just 
sits there in the corner under some magazines on top 
of your power supply. And it just keeps working and 
working and working, right? Well, usually but not al- 
ways! 

W5NUI recently pointed out a potential trouble spot 
with many TNCs. He and KA7UPD use “early” PK232s 
which have the RAM backup battery mounted on the 
top cover of the TNC, above the circuit board. What do 
batteries do when they get old? They leak! And that 
leaking battery acid drips down on the circuit board. 
It does a great job on a circuit board. 


This brings us to the discussion point: If your TNC 
is more than a few years old, it would be smart to re- 
place the backup battery. The battery cost should be 
no more than a few dollars. I cannot find any reference 
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to battery replacement in my MFJ-1270/1274 manual. 


If you don’t replace the battery, at least look at it 
every year or so. Watch for corrosion, liquid, or 
crystal growth. By the way, the same goes for the 
backup batteries in your computer and other 
electronic equipment including HTs, computers and 
smoke alarms! W5NUI suggests replacing such 
batteries on a regular annual event (your birthday, a 
holiday, etc); he also suggest taping a small tag with 
the date of most recent battery replacement to the 
outside of equipment 

You should plan on loosing all of the TNC parameters 
when you replace the battery. I keep a list of all the non- 
default parameters on a card near my TNC. This helps 
me to remember what needs to be set and to what value. 


—KA7EHK 
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NAPRA Bylaws 


Cf Board Member Alternates 

Spade Each direct int an Alternat h 

a. The name of the organization is Northwest Amateur a a4 re i ae ge 4 on ey hy foci Ue 
Packet Radio Association. or tH 4 ites ee ngs in the event that the director is 

b. The organization is also known as NAPRA. . Li atk . a mt pis d ot Werte Bourd 

c. The Pacific Northwest is defined to include Idaho, Mon- d is cae - ay ir A phd S ities Mei ‘4 : 4 a 
tana, Wyoming, Oregon, Washington and the bordering Ly ee eames a art Spi d . , Al ae 
ees PnitiesantBritish:Cohombia andwlberta. Reaeeres ot the Sins idate for Alternate and the Alternate 

must be present. 

2. Purpose c. The candidate for Alternate must 

; : give consent. 

a. NAPRA's purposes are: d. The candidate for Alternate must not be a board member 

b. to promote packet networking and packet radio in the or an Alternate already. 

Pacific Northwest. e. Appointment of an alternate may be discontinued at any 
ce. to publish the Dedicated Link. board meeting that the Alternate is not fullfilling his/her 
d. t blish the Annual . : 

PU a AA ON eg SE ho task of representing a director, at the request of the 

to provid rt f t d : 4 
e. to provide support for emergency operations and emer- director the Alternate represents, at the request of the 

gency operation planning. Alternate, or with a majority or tie vote of all the directors 

3. This Document present. 

a. These are the Bylaws of NAPRA. f. The Alternate appointment is automatically cancelled 

b. This document lays down the rules for operation of the when 
Northwest Amateur Packet Radio Association. No other ¢ the Alternate is elected to a board position; 
document may change or replace the rulessetdowninthe ¢ the Alternate is no longer a voting member; 

Bylaws. The Bylaws may only be modified by the proce- ¢ the member the Alternate represents is no longer on the 

dures described herein. board; 

c. If there is a conflict between a portion of this document —_g._ The Alternate has full voting rights at board meetings in 
and state or federal laws then state and federal laws the absence of the director which he or she represents. 
supersede that portion of this document. h. The Alternate must be in frequent communications with 

4. Membership Standards and Practices (MS&P) the director so that if the director is unable to appear at 

a. The MS&P is a document maintained by the board of a board meeting the alternate will be able to take his or her 
directors of NAPRA which describes all club resolutions, place in discussion and during votes. Failure in this 
policies and member responsibilities. communications is a sign of poor alternate choice. 

b. The MS&P is modified by a single vote of the board of 8. Membership 
directors, at a regularly scheduled board of directors a. There are at least two grades of membership, associate 
meeting and by a simple majority of the attending board and voting. 
members. b. Associate membership is available to all. 

c. There are no club policies besides those listed in the c. Associate members receive the Dedicated Link and An- 
MS&P and these Bylaws. nual. 

5. Directors e. Voting membership is available to all except those specifi- 

a. There are six members of the Board of Directors hereafter cally excluded by the terms of Revocation. 
ealledithe: board. f. Voting members receive all club benefits that Associate 

b. Members of the board are elected for two year terms. members receive in addition to those benefits described 

c. Members of the board are known as Directors. herein. 

d. Directors are elected annually such that three directors’ ©: Voting members are invited to all quarterly board meet- 
terms will end each year. ings by timely Paiste Link issues or by specific 

invitation via packet radio. 

.; Officers and Appointed Positions f. Voting members participate in elections. 

a. Office positions include Recording Secretary, Treasurer, Vv ih 
Membership Secre , g. Voting members may petition for special meetings. 

pts h. Associate members may upgrade to voting membership 
b. Appointed positions include board member alternates. 
at any time by sending the membership secretary the 
c. Other appointed positions may be created by the board. d 
ifference between an annual associate membership and 

These positions may be filled by vote of the board. These Ee sie niieoaienstiindexccnt inwhewaseot 

appointments may be changed or dissolved by the board. Revecntion 6 Ps P hee 

d. The MS&P must be changed if appointed positions are ! 
bpentbdianalsenieel i. Membership is granted immediately upon an officer or 

. director of the club receiving an application and funds. 

e. Only voting members may be appointed to a committee 

j. More benefits and membership classes may be described 
chairmanship, board member alternate or office position. in the MS&P 

f. Directors may serve as officers or other appointed posi- 
tions and appointees may serve multiple appointments. 

g. temporary committees are not appointed positions. 


SS 
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Board of Directors Meetings 


. A Board of Directors Meeting, hereafter called a board 


meeting, is a physical gathering of the directors and 
officers. 


. Aminimum of 4 directors (or alternates) must be present 


to open a board meeting. The board meetings must be 
announced via the NAPRA Dedicated Link or via packet 
mail to every voting member at least two weeks before the 
meeting. 


. The board meeting is chaired by one director, selected in 


advance. 


. The agenda of the board meetings will be created in 


advance of the board meeting. The chairman of the 
coming board meeting is responsible for coordinating the 
agenda creation process. The board members are ex- 
pected to participate in the creation of the agenda and 
their input will reflect the concerns of the membership as 
expressed to them. A member may communicate with 
any director to recommend agenda items and proposed 
resolutions. The director is responsible for communicat- 
ing this information to the board chair. 


. If a quorum of directors is not available to start the 


meeting a new meeting must be scheduled and new 
announcements must be sent. 
A quorum of directors is defined to be four directors. 


g. If a meeting must be postponed a new meeting must be 


10. 
. NAPRA General meetings may be called by any member. 
. The meetings must be scheduled in advance so that they 


oO 


scheduled and new announcements must be sent. 


. Board meeting locations are chosen such that travel time 


for all members in the Pacific Northwest is minimized 
without playing favoritism to any metropolitan area. The 
meeting must be in a location central to the Pacific 
Northwest. 

Board meetings may be attended by voting members or 
those given special dispensation by the board or any 
person approved by the MS&P. 

Board meetings must be held 4 times per year. The 4 
quarterly board meetings are held as close as possible to 
the second weekend of January, April, July and October. 
Additional board meetings may be called by the board 
with a vote of 4 directors. A board meeting is required in 
order to: 

spend club funds. 

discipline a member; 

change the appointment for chairman of any committee. 
re-assignment or assignment of a board member alter- 
nate; 

change the Bylaws or MS&P; 

form or disband any committee. 


. Actions which must occur at the board meeting include 


the reading of a current NAPRA treasury report. This will 
be recorded in the minutes and printed in the subsequent 
NAPRA Dedicated Link. 

Voting members who attend a board meeting may partici- 
pate in discussion. 


General Meetings 


may be published in the Dedicated Link. 


. Regular scheduled meetings on a monthly or quarterly 


basis are recommended. Minutes need not be taken but 
notes should be taken so regular reports may be pre- 
sented to the membership via the Dedicated Link or via 
reports at the board meetings. 
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. Conclusions and resolutions from general meetings may 


be presented at board meetings to be included in the 
MS&P if the board so chooses. 


. NAPRA documents, products and projects may be shown 


or created at general meetings. 
The format of general meetings is open but recommenda- 
tions for format are presented in the MS&P. 


. Club officers and directors are requested to attend as 


many of the general meetings as possible and to host 
general meetings in areas where meetings do not occur. 


. NAPRA general meetings should not be in competition 


with other packet clubs. 

At NAPRA general meetings funds might be raised for 
packet projects but those projects and the funds involved 
must be maintained by an individual or by an entity 
separate from NAPRA. If NAPRA is a hindrance to this 
procedure it is recommended that the group that meets 
at the particular general meeting form it’s own separate 
club. NAPRA will lend whatever documentation, leader- 
ship, or advisory assistance it may to help this procedure. 


Special Meetings 


. 20% of the membership may call a special meeting of the 


membership by petition. 


. The petition is presented by certified mail or in hand to the 


recording secretary, or if the recording secretary is un- 
available, to the current Board chair. 


. The recipient of the petition is responsible for the verifi- 


cation of the petitions and for distribution, to the other 
directors. 


. After verification that the petition meets the qualification 


for calling a special meeting the meeting shall be sched- 
uled at the city of the last board meeting within 90 days 
of receipt of the petition and no sooner than 30 days after 
notices to members are mailed. 


. Notices to all members must be mailed within thirty days 


of the receipt of the petition. The notice shall consist of 
the text of the petition in the form of an agenda and only 
items on the agenda will be eligible to be voted on. 

Special meetings may also be called by a vote of four of the 
directors if justified by the Disolution clause, over the 
phone or in person, in which case the chairman of the 
board, or the recording secratary is notified. The direc- 
tors who call the meeting, in this case, create the agenda. 


. The meeting will be called to order by the current chair- 


man of the board. The current club recording secretary 
shall record minutes of the meeting. These minutes will 
be published in the next Dedicated Link. 


. A quorum will be 20% of the membership. 


The remaining directors will have no special powers at the 
meeting. 
The meeting will follow strict interpretation of Roberts 
Rules of Order, revised, except where contradicted by the 
Bylaws. A parliamentarian should be on hand during this 
meeting. 


. Special meetings may be used to: 


make immediate changes to the Bylaws, 

make immediate changes to the MS&P, 

elect or appoint new officers and directors, 

spend club funds, 

remove officers or directors, 

dissolve the club, 

approve documentation, 

or for assignment or revocation of a member's privileges. 
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13. 
. Amailed ballot is used to elect directors. 

. Elections are held after the October board meeting. 

. Immediately after the October board meeting attendance 


ome) 


eeee @cu 
° 


Removal of a Person From Office or Revocation 
of Votiong Membership Privileges 
A petition for removal of a person from office, directorship 
or voting membership must be submitted in writing to the 
board with a minimum of four signatures of voting 
members. 


. The petition must be presented at least two weeks before 


a quarterly board meeting in which it is to be acted upon. 
The board must vote on the petition at a quarterly board 
meeting. 


. The document will be kept in the club archives unless 


removed and expunged at a later board meeting. 


. This issue is presented in the minutes in the Dedicated 


Link so that it may be reviewed by all the membership and 
commented on before the following quarterly board meet- 
ing. 


. This person being removed is held as a removal-pending 


member for one quarter and then is reviewed at the 
following quarterly board meeting. 

A person removed from membership is not eligible for 
voting membership unless the privilege is restored by an 
act of the board at a later date. 


Elections 


of each member, over the previous year’s board meetings, 
are tallied. Any voting member who is paid up for two 
years from the end of October of the current year, who has 
attended half of the year’s board meetings, and who are 
not already in the middle of a two year term are automati- 
cally nominated. 


. The nominees are informed via packet and have two 


weeks to request that they not be listed on the ballet. 


. The membership may request, by petition, that addi- 


tional voting members are placed on the ballet. The 
petition must include the minimum of 5% of members or 
700 signatures, whichever is less, and must be presented 
to the board chairman or recording secretary within two 
weeks after the October board meeting. 

This ballot is sent to all NAPRA voting members complete 
with a self addressed stamped envelope. The envelope 
also has areturn address label with a note stating that the 
return address must be filled in for the ballot to be 
counted. 


. The ballot includes instructions that the voting member 


should order all of the listed people in ascending order, 1 
for first choice, 2 for second choice. This way the results 
will still be meaningful if one or more nominated members 
are unavailable to fill the positions. 


. The ballots are mailed to the club POBox and then 


counted by the recording secretary or one of the directors 
whose term is not expiring this year. 

The ballots must be mailed out to all NAPRA voting 
members between 14 and 30 days after the October board 
meeting. They must be returned to the club mailing 
address within five weeks of the mailing. Results are 
included in the Dedicated Link or are mailed out sepa- 
rately to all members to arrive at least a week before the 
winter board meeting. 

The results include the following statistics: 

total number of ballots sent; 

total number of ballots returned.; 

list of all nominees; 

list of the new directors; 

and alist of nominees who abstained but who had a higher 
vote than the selected directors. 


k. 


14. 
. Directors must attend the quarterly board meetings or 


15. 


If the board is not filled to six directors by this process 
then a director may be chosen by the existing board from 
those voting members who were previously directors and 
who ended their term as director in good standing. See 
Grounds for Dissolution. 


Director Responsibilities 


obtain an alternate to handle meetings the director 
cannot attend. Failing to do so twice in a single year is 
grounds for removal from office. Directors or their 
alternates are also obligated to attend additional board 
meetings called by verbal agreement by any four of the 
directors. 


. Directors represent NAPRA and are obligated to carry out 


the NAPRA Bylaws and MS&P in regards to dealings with 
other members and non-members. 


. The board as a body is responsible for seeing that the 


NAPRA Dedicated Link and the NAPRA Annual are 
published on time. As these are the instruments of the 
club and as the NAPRA Dedicated Link is the means by 
which the financial operations of the club are published 
to the membership, the paying membership has the right 
to expect these documents. 


Filling Spots on the Board Due to Director 
Resignation 


. Ifa director resigns or is otherwise no longer available to 


fulfill the remainder of his or her term a new director is 
selected to serve until the next election. 


. The new director is selected from those voting members 


who were previously directors and who ended their term 
as director in good standing. 


Dues & Club Treasury 


. Dues are paid to the Membership Secretary or his 


designee. 


. All funds are then forwarded to the Treasurer. 
. Dollar values of dues is set in the NAPRA MS&P but the 


dues level for a Voting member is $25 or greater. 


. Dues are not refundable 
. Dues may only be used to fund: 


operating expenses for the club; 

one night's stay, per meeting, in a budget motel local to 
the meeting site for each director or officer that needs to 
travel in excess of three hours to the board meeting, the 
benefit per individual not to exceed four nights stay for the 
entire year and this amount not to compromise the ability 
of the club to publish the Dedicated Link and Annual. 
development costs for club products that facilitate net- 
work growth; 

documentation in the form of an Annual and Dedicated 
Link; 

documentation in the form of free technical documenta- 
tion distributed for the benefit of packet networking; 
documentation in the form of free promotional literature 
on NAPRA and on packet networking; 

Funds may not be spent on hardware which might 
otherwise be purchased by a member; 


. The purpose of NAPRA funds is to promote packet 


networking, not to own packet networking; 


. Items donated to the club must eventually be sold or 


donated to support youth activities in the Pacific North- 
west and in the country from which the donation was 
received. Such transactions must be documented in the 
Dedicated Link. 

Equipment must not be owned by the club when it could 
instead be owned and operated by a member. 


nS SS 
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17. 
. Network maps must be maintained and are presented in 


Items may be obtained or accepted as donation by the 
club for the purpose of testing new networking technolo- 
gies not already implemented in the Pacific Northwest. 


. Items may be accepted as donation by the club and kept 


by the club where those items are not used for packet 
networking but are of value in the documentation process 
and in the operating of the club. The finaly disposition of 
such items will be as in 16h, above. 


Network Maps 


the Dedicated Link. 


. The maps must consist of at least the callsign, name, 


location (at least relative), user access frequencies for 
AX.25 (if any) and backbone connectivity for listed nodes. 


. Listed nodes include all point to point connected general 


access nodes in the Pacific Northwest. 


. Ageneral access node is a node through which any AX.25 


equipped station is able to pass traffic, in real time. 


. Nodes that do not participate in a general access network 


are marked as such or are not shown. 
The maps may show more information, as described in 
the MS&P. 


NAPRA Dedicated Link 


. The NAPRA Dedicated Link is published within 60 days 


after the quarterly board meeting. 


. The Dedicated Link is fully described in the MS&P but as 


a minimum must include: 

the minutes of the board meeting (including the treasurer's 
report); 

the network maps; 

membership roster; 

any submitted club bulletins from packet user groups and 
special interest groups that reflect packet activity in the 
Pacific Northwest during the preceding quarter. 


c. The board may delegate the task of production and 
mailing of the Dedicated Link but maintain the responsi- 
bility. 

d. The fall edition of the Dedicated Link will include what- 
ever results that are available from the annual elections. 
This may include the nominees or the final results. 

19. NAPRA Annual 

a. The NAPRA Annual is the current statement of NAPRA 
packet network involvement. This includes user informa- 
tion for usage of general access network hardware as well 
as lessons in the technology needed to fulfill the goals of 
NAPRA as stated in these Bylaws. 

b. The Annual is delivered annually to each and every paid 
member of the club. 

c. The Annual should be updated at least once annually to 
reflect the current state of networking technology pro- 
moted by NAPRA. 

d. The Annualis the responsibility of all of the directors. The 
board may delegate the task of production and mailing of 
the Annual but maintain the responsibility. 

20. Changes to the Bylaws 

Changes to the Bylaws may only be made by the following 

process: 

a. At a regularly scheduled quarterly board meeting a 


proposal for a change is submitted in printed or typed 
form (8 copies) to each of the Directors, to the editor and 
to the recording secretary. The item must be presented 
in person by a NAPRA voting member. 
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21. 


22. 


23. 
. Inthe event of dissolution: After paying out any pending 


The format of the submission is in bulleted sections. The 
following sections must be included: TITLE, PRESENTED, 
BY, BRIEF, SPECIFICS, PURPOSE. The page is headed 
with “Bylaws Change Request”. TITLE is followed by one 
line which identifies the change request. PRESENTED is 
followed by the date of the board meeting. BY is followed 
by the name and callsign of the author. BRIEF is followed 
by a single paragraph description of the change. SPECIF- 
ICS is followed by a paragraph by paragraph description 
of the changes including reference section and paragraph 
numbers. PURPOSE is followed by a justification for the 
change. A sample change is available from the club. 
The proposed change is entered into the minutes of the 
board meeting at which it is presented. Discussion may 
follow. No vote is taken at this time. 


. At the following board meeting the change is brought up 


as old business and after discussion is either ratified or 
not. No change is made if a tie occurs. 

If a change is ratified then the new copy of the Bylaws is 
printed in the following Dedicated Link in its entirety. 


Changes to MS&P 
Changes to the MS&P may be made at a single board 
meeting with the vote of a majority of the directors 
present. If a tie occurs then no action is taken. 


Grounds for Dissolution 
If the board doesn’t make reasonable effort to hold 2 
board meetings before the end of July then a special 
meeting must be called within 90 days. If the special 
meeting is not able to be called to order, due to misman- 
agement or lack of quorum, the club must be dissolved. 


. Ifduring the year, four board meetings are not called then 


all six directors must be up for re-election. 

If the board doesn’t make reasonable effort to get the 
Dedicated Link, in at least it’s minimum form, mailed to 
the membership in time, then a special meeting must be 
called within 90 days. If the meeting is not able to be 
called to order, due to mismanagement or lack of quorum, 
the club must be dissolved. 


. Ifthe clubis unable to hold elections or it was not possible 


to fill all board vacancies in a timely manner then the club 
must be dissolved. 


Dissolution of the Club 


bills the treasurer is directed to write a check for the 
remainder of the club treasury to the American Cancer 
Society and to close all club bank accounts. 


© Northwest Amateur Packet Radio Association, 
1992 
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NEDA HexiPus™ Order Form 


Use this order form when purchasing HexiPus™ 
board kits by mail from the POBox or from a NEDA 
consignee at a special event. 

Use the latest version of this form if possible. See 
bottom of the page for release date. 

You do not have to pay shipping if you are get- 
ting the HexiPus™ from a NEDA agent/consignee. 

To Consignee: Please make sure that each pur- 
chase is handled with one of these forms. Correctly 


document funds exchanged, check numbers, 
purchaser's name and address if not by cash; and 
quantities of each kit type delivered. 

To Mail Purchaser: Please fill out all sections of 
the form except those marked "For Office Use Only’. 

This will help our treasurer track the sales of the 
product so that our club may be run efficiently and 
above board. 

Thank you and good luck with your node! 


Purchaser Information 


Name 


Address 


State/Province 


City 


Callsign (Optional) 


YCash Check Number WUS bank WCanadian 


bel ee 


Amount J If funds are Canadian compute 
exchange rate as best you can. 
If check is drawn on a Canadian 
bank add $5 U.S. to total. 


# of Complete Kits 
(US) 
- x$29.95 


subtotal in US funds 


If by mail add $4.00 per unit 
No mail delivery outside U.S. 


Total in US funds 


Agent/Consignee Information 


Name 


Notes: (specify connector type, male/female) 


J 


The NEDA HexiPus™ Kit is, as of this printing, 
available in three formats. Board with diodes; 
Board with diodes and female connectors; or board 
with diodes and male connectors. The supply of 
the female connectors is limited as they were pur- 
chased surplus. Please specify your preference in 
the notes section above. The shipper will give you 
male connectors if females run out. 


NEDA: Box 563 Manchester NH 03105 


Order Form Date: 10/8/92 
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This page left blank so as to not mess up the paperwork at NEDA's office. This has been a complaint 
in the past. Please have your 4 year old daughter (or son) scribble all over this side of the page just 
to keep Howie's (the NEDA Hexipus Committee chairman) life interesting. If you don't have a 4 year 
old daughter (or son) borrow one of your neighbors. Thanks. 
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Northwest Amateur Packet Radio Association Membership Application 


Welcome to NAPRA and Packet Radio. This is the official 
membership form for NAPRA. 


Some general information about NAPRA: 

NAPRA is a club formed in the mid 80s for the purpose of de- 
veloping and promoting packet radio technology. NAPRA's pur- 
pose and bylaws were changed in spring of 1992 to focus on the 
promotion issues involved in modern day packet radio network- 
ing. 

NAPRA's area of interest includes Montana, Wyoming, Idaho, 
Oregon, Washington, and southern parts of Alberta and British 
Columbia. 


NAPRA publishes the Dedicated Link as a periodical four times 
a year. The NAPRA Notebook is published each year as well. 
Subscribers and Voting Members receive these documents by 
mail. Club members may aquire copies to distribute at flea mar- 
kets. 


NAPRA's administration is based on 6 directors, 6 director al- 
ternates and several appointees. The six directors of the board 
are elected by the membership for two year terms. The six al- 
ternates are appointed by the elected board. Three of the direc- 
tors are elected each year. The appointees include recording 
secretary, membership secretary, treasurer and editor. The 
board meets four times a year in a location central to the club's 


Membership Applying for - Check one box: 


Enter # of years 


you wish to pay for: Amount Enclosed: 


Address: 


Callsign: 


Other Computer addresses we can contact you at: 
(TCP/IP, FIDO Net, Internet, CompuServe etc.) 


lf a NAPRA member gave you thi 
form, what is his or her callsign? 


interest, put your county here: 


area of interest. Those meetings are open to the voting member- 
ship and are fully documented in the minutes which are published 
in The Dedicated Link. The club bylaws are available with a 
SASE to the club's mailing address. 


NAPRA members sponsor general interest and specific inter- 
est packet meetings throughout the region of interest of the club. 
Those meetings may be announced in The Dedicated Link and 
meeting results may also be published. Other packet radio clubs 
can request space in The Dedicated Link. NAPRA's focus is to 
publish information on packet radio and packet radio networking. 


The dues structure of NAPRA is as follows: 


Subscription membership in the United States ...............615 
Voting membership in the United States ........ eee $25 
Subscription membership with Canadian address.......... $20 
Voting membership with Canadian address ................... $30 
Life membership in the United States .........eeeeeeeeeee $500 
Life membership with Canadian address .............:s0ce $600 
Upgrade to voting membership all countries................. $10 


All membership rates are US funds only. Canadian applicants 
should send funds in a Postal or Bank Money-Order in US funds. 
Non-US or Canada applicants, libraries and other Amateur Ra- 
dio clubs should contact NAPRA at the mailing address for infor- 
mation and rates. Thank you. This form is dated DL1-010193. 


Packet Home BBS: 


Home Phone: 


If you are a RACES or ARES member in NAPRA's area of 


Make Checks to NAPRA. 
Address this form and all other correspondence to: 
NAPRA 

Box 70405 
Bellevue WA 98007 


State or Province 


City: 
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TheNET SOT s Help Sheet 


Parameter Function v2.08 L F Note: See pages 51 through 56 of this 
1 i m Quality For Auto Update 50 50 50 is 
Bimmiccieekae 1 Sy § Goma Notebook for definitions and descriptions of 
3  RS-232 Channel Quality 203 203 82 203 
4 Obsolescence Count Init Value 3 3 3 3 the parameters. 
5 Obsolescence Count Min For Broadcast 4 4 1 1 Parameter Function X1, 1.1 & 1.16 WwW i F Pp 
6 Nodes Broadcast Interval (sec) 900 900 900 900 1 Destination List Length 100 100 100 100 
7 FRACK (sec) 8 5 3 1 2 Minimum Quality For Auto Update 50 50 50 50 
8 MAXframe 1 1 1 1 3 HDLC Channel Quality 50 0 82 0’ 
9 Link RETRIES 6 10 6 10 4 RS-232 Channel Quality 203 203 82 203 
10 Digipeating 0=no; 1=yes (¢) 0 0 0 5 Obsolescence Count Init Value 3 3 3 3 
11 Validate Callsigns O=no; 1=yes 0 1 1 1 6 Obsolescence Count Min For Broadcast 4 4 1 1 
12 Host Mode Connects 0 0 0 0 7 Nodes Broadcast Interval (sec) 900 900 900 900 
13. TxDELAY (10ms) 35 35 35 35 8  Time-to-live Initializer (hops) i 7 if 7 
14 Broadcast Via bO=radio; b1=RS-232 3 2 3 3 9 Transport Timeout (sec) 200 200 200 200 
15 Pound Node Propagate O=no; 1=yes 0 0 0 0 10 Transport RETRIES 2 2 2 2 
16 Connect Command Enable 0=no; 1=yes 1 1 1 0 11 Transport ACK Delay (sec) 1 1 1 1 
EPROM parameters 12 Transport Busy Delay (sec) 120 120 120 120 
17 Destination List Length 100 100 100 100 13 Transport Window Size 2 2 7 2 
18 Time-to-live Initializer (hops) 7 a Té 7 14 Congestion Control Threshold 4 4 4 4 
19 Transport Timeout (sec) 200 200 200 200 15 No-Activity Timeout (sec) 7200 7200 #300 300 
20 Transport RETRIES 2 2 2 2 16 P-persistance (see text) 64 255 64 255 
21 Transport ACK Delay (sec) 1 1 1 1 17 Slot Time (10ms) 35 1 35 1 
22 Transport Busy Delay (sec) 120 120 120 120 18 FRACK (sec) 8 5 3 1 
23 Transport Window Size 2 2 2 2 19 MAXframe 1 1 1 1 
24 Congestion Control Threshold 4 4 4 4 20 Link RETRIES 6 10 6 10 
25 No-Activity Timeout (sec) 7200 7200 300 300 21 Link RESPTIME [t2 timeout] (10ms) 100 30 50 20 
26 P-persistance (see text) 64 255 64 255 22 Link T3 Timeout [CHECK] (10ms) 65000 65000 65000 65000 
27 Slot Time (10ms) 35 1 35 1 23 Digipeating O=no; 1=yes 0 0 0 0 
28 Link RESPTIME [t2 timeout] (10ms) 100 30 50 20 24 Validate Callsigns O=no; 1=yes 0 1 1 1 
29 Link T3 Timeout [CHECK] (10ms) 65000 65000 65000 65000 25 Station ID 0=msgs;1=after; 2=always 1 2 0 0 
30 Station ID O=msgs;1=after; 2=always 1 2 0 0 26 CQ Broadcasts O0=no; 1=yes 1 1 0 0 
31 CQ Broadcasts 0=no; 1=yes 1 1 0 0 
32 Heard List Length 20 20 20 20 
33 Full Duplex 0=no; 1=yes 0 0 0 0 Note 1: Link qualities for Point to Point backbones and 
Parameter Function v2.10 w L F P hidden transmitter free multi-way backbones is 203. 
eee Mu aiy For Auto Update} =~ 50 50, S050 EPROM defaults should be set to 0 and the desired 
2 HDLC Channel Quality 50 0 82 0! : 
3 RS-232 Channel Quality 203 203 «= 82~—Sts«08 route(s) should be locked in. 
4 Obsolescence Count Init Value 3 3 3 3 ee 
5 Obsolescence Count Min For Broadcast 4 4 1 1 Definitions of port types: 
6 Nodes Broadcast Interval (sec) 900 900 900 900 W Wide coverage public access port for access to all 
7 FRACK (sec) 8 5 3 1 : 
SANs 1 y y ; network services. 
9 Link RETRIES 6 10 6 10 L_Local coverage user port for access to all network 
eae 3 ‘ ; services. This kind of port must not hear any 
12 TxDELAY (10ms) 35 35 35 35 other on-channel servers, nodes or high volume 
13 Broadcast Via bO=radio; b1=RS-232 3 2 3 3 5 
14 Pound Node Propagate O=no; 1=yes 0 0 0 0 users of a kind. z 
16 Destination List Length 100 100 100 100 frequency (usually 220 or 440) which has more 
17 Time-to-live Initializer (hops) 7 7 7 té th th d hich vol 
18 Transport Timeout (sec) 200 200 200 200 an one otner node, server or 18 volume user. 
19 Transport RETRIES 2 2 2 2 P_ Point to Point backbone port. This port faces 
20 Transport ACK Delay (sec) 1 1 1 1 . : : 
Si, Transpo Bilsy Delay (sec) ee eee a exactly one other station. This station and the 
22 Transport Window Size 2 2 2 2 other station are optimized for this duty. 
23 Congestion Control Threshold 4 4 4 4 
EPROM parameters 
24 No-Activity Timeout (sec) 7200 7200 #8300 300 
25 P-persistance (see text) 64 255 64 255 
26 Slot Time (10ms) 35 1 35 1 
27 Link RESPTIME [t2 timeout] (10ms) 100 30 50 20 
28 Link T3 Timeout [CHECK](10ms) | 65000 65000 65000 65000 
29 Station ID O=msgs;1=after; 2=always 1 2 0 0 . 
30 CQ Broadcasts 0=no; 1=yes 1 1 0 0 This drawing represents the node quality 
31 Full Duplex O=no; 1=yes (0) 0 0 0 : ; 
32. Port Direction (future) ; 5 ‘ 4 value for a single node as it propagates 
33 Multiplier (future) 0 ) 0 0 through several node hops. 

Local node user port 1st neighbor user port 2nd neighbor user port 3rd neighbor user port 

broadcasts 256 = 128 = 81 =51 
4 backbone link backbone link § backbone link 


203 203 


161 


128 


102 81 
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The Northwest 


Montana, Wyoming, Idaho, Oregon, Washington, 
lower Alberta, lower British Columbia. 
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